Repository navigation
An X509 peer should support RPK too #2145
Description
Activity
Yeah, I think this could be improved. Mainly we seem to be missing a way to tell the full certificate to encode itself as RawPublicKey, and as you say we might want a method that can restrict what the server is willing to do.
In BCJSSE, ProvTlsServer creates and saves the credentials during selectCipherSuite, then just returns that single instance for any getCredentials calls. So once per handshake. Usually we try to store things in the protocol if they are needed more than once, but in this case the second call crept in via a PR. There's plenty of example code that predates that second getCredentials existing.
- added a commit that references this issue
on Aug 22, 2025 I tried to experiment a way to solve that.
The bouncy castle modification 👉 sbernard31@69e3e20
How it is used in my code 👉 eclipse-leshan/leshan@bd5fd85
In my case that works.
But this is a bit error prone that at first call ofgetCredentials()context.getSecurityParametersHandshake().getServerCertificateType();always return default value :CertificateType.X509With that in mind, I not so sure this is good idea to have default implementation for
getSupportedServerCertificateTypeswith current state of the code. 🤔I tried to explain a bit more why :
Currently user need to implements
getCredentialsto return aBcDefaultTlsCredentialedSigner
We try to guessServerCertificateTypefrom it.
But that works not so well if server support several kind of signer.
CertificateType is needed to select signer but we try to find CertificateType from signer.
(This also lead to 2 call togetCredentials)Maybe a better way would be to provide a more high level API to set credentials.
Then from that we can guess supportedCertificateTypes.
Then from selected server certificate type (after negociation) + that credentials, we can automatically create a default signer.More high level credentials API would be way to provide :
- private key
- public key or certificate chain
Let me know if this makes sense or if you have better idea ?
@peterdettman any feedback about that ?
@peterdettman @winfriedgerlach
Feedback would be appreciate.
Or at least let me know what is a best way to help on this.
Or maybe that kind of contributions are not really welcomed, some time project are open source but doesn't have a real open development spirit (which is also OK)@sbernard31 sorry, I am really just the "label janitor", I cannot answer your question. From what I observe at other tickets, contributions are welcome but it sometimes takes longer until they are picked up. Don't give up yet :-)
In my case I have a DTLS server (using bouncy castle low level API), which need to support PSK, RPK and X509.
A peer which support X509 could support RPK too.
Of course, it should be possible to configure that peer in a way it only accept X509.
Currently, it seems there is a bug (or missing feature) which prevent to create a server which accept both.
A comment in the code seems to confirm that:
bc-java/tls/src/main/java/org/bouncycastle/tls/AbstractTlsServer.java
Lines 605 to 606 in 0e100a5
Maybe it make sense to try to find supported Server Certificate Type based on getCredentials() but in case this is X509 certificate, maybe RPK should be added too by default ?
Maybe we should have a getSupportedServerCertificateTypes() in AbstractTlsServer with default implementation based on
getCredentials, so it would be easy to override it change default behavoir.(Bonus question, as there is not so much documentation, it is often hard to know what is expected when implementing BC interface/abstract class, typically for getCredentials() should I a create a BcDefaultTlsCredentialedSigner on each call ? I guess at least 1 by handshake and so it should be simpler if getCredentials was called only 1 time by handshake ? currently it is called twice, 1 time to get Server Certificate Type and one time to store it
ServerHandshakeState.serverCredentials)