gnodet commented on PR #22194:
URL: https://github.com/apache/camel/pull/22194#issuecomment-4130562200

   ## Self-Signed Certificate Generation: Framework Comparison
   
   For context on the approach we took with `SelfSignedCertificateGenerator`, 
here's how other frameworks handle self-signed certificate generation:
   
   ### Netty
   Uses a **two-tier fallback**:
   1. **BouncyCastle** (preferred) — `X509v3CertificateBuilder`, 
`JcaContentSignerBuilder`, etc.
   2. **OpenJDK internal APIs** (fallback) — `sun.security.x509.*` classes 
(`X509CertInfo`, `X509CertImpl`, `X500Name`, etc.) via reflection
   
   Both have downsides: BouncyCastle is a heavy optional dependency, and 
`sun.security.x509` classes are internal JDK APIs increasingly restricted by 
module encapsulation. Netty is currently discussing ([PR 
#14263](https://github.com/netty/netty/pull/14263)) adding a separate module 
with **their own DER encoder** — essentially the same approach we took here.
   
   ### Vert.x
   Delegates entirely to Netty's `SelfSignedCertificate` (wraps `new 
io.netty.handler.ssl.util.SelfSignedCertificate(fqdn)`).
   
   ### Quarkus
   Uses **SmallRye Certs** library (`io.smallrye.certs.CertificateGenerator`) 
which depends on **BouncyCastle** (`BouncyCastleProvider`). Available via CLI: 
`quarkus tls generate-certificate --self-signed`.
   
   ### Our Approach (Camel)
   Our `SelfSignedCertificateGenerator` builds the DER-encoded X.509 
certificate directly using **standard JDK APIs only** (`KeyPairGenerator`, 
`Signature`, `CertificateFactory`) — no internal APIs, no BouncyCastle 
dependency:
   
   - **Lightest approach** — zero extra dependencies
   - **Most forward-compatible** — no `sun.security.x509` or `--add-opens` 
needed
   - **Aligned with Netty's direction** — they're moving toward their own DER 
encoding too
   - **Explicit opt-in** — requires `camel.ssl.selfSigned=true`, just like 
Quarkus requires `--self-signed`
   
   _Claude Code on behalf of Guillaume Nodet_


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to