Test an unusual split between context and connection configuration
No one would ever do this, but it works today and we should keep it
working. As part of certificate selection, we'll be introducing an
SSL_CREDENTIAL object. In doing so, the existing APIs will mutate a
built-in "default" credential. If we made a shallow copy, it would break
things.
Bug: 249
Change-Id: I75b1486289659611184a42e87771a6cf7ddb5aa7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66372
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
diff --git a/ssl/ssl_test.cc b/ssl/ssl_test.cc
index 404e38d..3595204 100644
--- a/ssl/ssl_test.cc
+++ b/ssl/ssl_test.cc
@@ -8990,5 +8990,38 @@
}
}
+// Test that it is possible for the certificate to be configured on a mix of
+// SSL_CTX and SSL. This ensures that we do not inadvertently overshare objects
+// in SSL_new.
+TEST(SSLTest, MixContextAndConnection) {
+ bssl::UniquePtr<SSL_CTX> ctx(SSL_CTX_new(TLS_method()));
+ ASSERT_TRUE(ctx);
+ bssl::UniquePtr<X509> cert = GetTestCertificate();
+ ASSERT_TRUE(cert);
+ bssl::UniquePtr<EVP_PKEY> key = GetTestKey();
+ ASSERT_TRUE(key);
+
+ // Configure the certificate, but not the private key, on the context.
+ ASSERT_TRUE(SSL_CTX_use_certificate(ctx.get(), cert.get()));
+
+ bssl::UniquePtr<SSL> ssl1(SSL_new(ctx.get()));
+ ASSERT_TRUE(ssl1.get());
+ bssl::UniquePtr<SSL> ssl2(SSL_new(ctx.get()));
+ ASSERT_TRUE(ssl2.get());
+
+ // There is no private key configured yet.
+ EXPECT_FALSE(SSL_CTX_get0_privatekey(ctx.get()));
+ EXPECT_FALSE(SSL_get_privatekey(ssl1.get()));
+ EXPECT_FALSE(SSL_get_privatekey(ssl2.get()));
+
+ // Configuring the private key on |ssl1| works.
+ ASSERT_TRUE(SSL_use_PrivateKey(ssl1.get(), key.get()));
+ EXPECT_TRUE(SSL_get_privatekey(ssl1.get()));
+
+ // It does not impact the other connection or the context.
+ EXPECT_FALSE(SSL_CTX_get0_privatekey(ctx.get()));
+ EXPECT_FALSE(SSL_get_privatekey(ssl2.get()));
+}
+
} // namespace
BSSL_NAMESPACE_END
