Repository navigation
feature: Support boringssl SSLCredential API #918
Description
Activity
@normanmaurer I'm curious to hear your thoughts on this.
will come back to you @jmcrawford45 soon
Also /cc @chrisvest
@jmcrawford45 @normanmaurer I can investigate this one. Good support for PQC is definitely something we want.
Reacted by Norman MaurerHi @chrisvest I wanted to check in on the progress on this one. If there's any way I can help (either with the JNI side for the API, early eyes on draft PRs, or verification on the integration), please let me know. In addition to the PQC support, we (Netflix) have an existing use case for dual EC/RSA serving that would benefit from this.
@jmcrawford45 I haven't been able to properly start working on this yet, as other Netty 4.2 issues have had to take priority. I don't think I'll have time for at least another week, so if you want to start a PR you can go ahead. We already have existing examples in the code for the hind of APIs that are needed. I think in netty-tcnative a fairly thin wrapper of the credentials API is good enough, and leave it to the corresponding netty PR to figure out how to present a nice API to integrators.
@chrisvest I threw together #935 with thin wrappers for all the existing SSL Credential apis
- added a commit that references this issue
on Aug 15, 2025 @jmcrawford45 @normanmaurer and anyone else who hit this, SSL_CREDENTIAL is not available on any version of BoringSSL that has worked its way through FIPS 140 CMVP yet. Here's the list of certs:
The latest cert is https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4953 which is pinned at https://github.com/google/boringssl/tree/fips-20230428, which is missing the commit that introduces the credential API (google/boringssl@91a3f26).
Sorry we didn't notice this sooner. We'll patch in an extra cdef to unblock ourselves. It looks like this feature is well isolated so may not be cause any more issues until the FIPS 140 certification catches up ...?
@mikedanese thank you for raising this issue, and apologies about the disruption. I I do see all the fips branches from fips-20240407 onward have the SSL_CREDENTIAL bindings, so hopefully when the next CMVP goes through, it will add support. In the meantime, I threw together #948. Will this allow you to remove your patch?
- added a commit that references this issue
on Nov 20, 2025
Title: Proposal for Integration with BoringSSL SSL Credential API
Description:
I would like to propose an integration with the BoringSSL SSL Credential API and am seeking feedback from the maintainers on their willingness to support this initiative. I am prepared to work on the code changes for the integration but wanted to check in here first.
Background:
Historically, BoringSSL lacked a built-in method to select between RSA and ECDSA certificates. The selection process, especially at TLS 1.2, is quite complex, as detailed in this link. TLS 1.3 simplifies this process significantly. Additionally, within ECDSA, there are different curves to consider, and future developments will introduce post-quantum key types.
Functionality:
With the proposed functionality, BoringSSL could in the future make various certificate negotiation decisions, such as:
SSL_CREDENTIAL Overview:
The SSL_CREDENTIAL is designed to configure these elements. It consolidates everything related to a single "credential" into an object. Credentials can vary in type, such as X.509 certificates or others. Each credential has criteria, based on TLS protocol rules, to determine its applicability to a connection. Users configure an ordered preference list of credentials, and BoringSSL selects the first matching one.
This approach can be used alongside application-specific selection logic, like SNI dispatch. End users would use their criteria to select a list of candidates, such as an ECDSA and RSA certificate for a host, configure them in preference order with BoringSSL, and BoringSSL will evaluate them according to protocol rules.
Relevant Links: