You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a custom SSLContext.TLS provider and extend SSLContextSpi by adding extra certs to our TrustManager. This provider is at the highest priority and takes precedence over our SunJSSE provider. I am wondering if adding BouncyCastleJsseProvider / ProvSSLContextSpi will conflict with our custom provider because the one provided by ProvSSLContextSpi will not have those extra certificates and it doesn't seem like there's a way to inject them. In other words, it seems anyone who wants bcfips and its TLS implementation, will lose control over how the SSLContext is initialized - specifically they cannot control the TrustManager and KeyStoreManager that are passed to the SSLContext. Is there a way to get around this limitation?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have a custom
SSLContext.TLS
provider and extendSSLContextSpi
by adding extra certs to our TrustManager. This provider is at the highest priority and takes precedence over our SunJSSE provider. I am wondering if addingBouncyCastleJsseProvider
/ProvSSLContextSpi
will conflict with our custom provider because the one provided by ProvSSLContextSpi will not have those extra certificates and it doesn't seem like there's a way to inject them. In other words, it seems anyone who wants bcfips and its TLS implementation, will lose control over how the SSLContext is initialized - specifically they cannot control the TrustManager and KeyStoreManager that are passed to the SSLContext. Is there a way to get around this limitation?Beta Was this translation helpful? Give feedback.
All reactions