While I'm not completely certain this is a common scenario, we observed this failure on upgrading to Netty 4.1.80 and when using a custom bundle for a private key.

From a quick glance, it looks like it should be resolved by ensuring that the input stream passed to the BouncyCastlePemReader is a copy, and processed independently of the original stream processed by PemReader

Netty version

4.1.80 w/ tcnative 2.0.54

JVM version (e.g. java -version)

openjdk version "17.0.4" 2022-07-19 LTS

Expected behavior

The PR #12670 introduced a change that enforces eager parsing by BouncyCastlePemReader when the classpath includes the BouncyCastleProvider

The intended behavior should be the fallback to PemReader kicking in when the key type does not match one of the supported variants.

Actual behavior

In the case where there is a BouncyCastleProvider on the classpath, but the key type is of a format that is not supported by BouncyCastlePemReader, the input stream has already been read.

This renders the fallback to trigger, but fails decoding.

Caused by: java.lang.IllegalArgumentException: Input stream does not contain valid private key.
        at io.netty.handler.ssl.SslContextBuilder.keyManager(SslContextBuilder.java:416)
        at io.netty.handler.ssl.SslContextBuilder.keyManager(SslContextBuilder.java:341)
        at io.netty.handler.ssl.SslContextBuilder.forServer(SslContextBuilder.java:84)
....
Caused by: java.security.KeyException: could not find a PKCS #8 private key in input stream (see https://netty.io/wiki/sslcontextbuilder-and-private-key.html for more information)
        at io.netty.handler.ssl.PemReader.keyNotFoundException(PemReader.java:156)
        at io.netty.handler.ssl.PemReader.readPrivateKey(PemReader.java:137)
        at io.netty.handler.ssl.SslContext.toPrivateKey(SslContext.java:1152)
        at io.netty.handler.ssl.SslContextBuilder.keyManager(SslContextBuilder.java:414)

Steps to reproduce

Use a key with a format not supported by the BouncyCastlePemReader, and trigger the fallback logic.