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