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>
This commit is contained in:
David Benjamin
2024-02-22 19:24:18 +00:00
committed by Boringssl LUCI CQ
parent 9a4e1095c0
commit 4fe29ebc75
+33
View File
@@ -8990,5 +8990,38 @@ TEST(SSLTest, NameLists) {
}
}
// 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