I’ve coded up the functionality to check all of the intermediate certificates to ensure that they match the private key of the crt file. I’ve decided to toggle this functionality as a config option. Users can either choose to disable this entire feature (default), match only the private key/cert, or match the entire certificate chain.
Should I keep sending out diffs? -Dave On 6/24/15, 11:54 AM, "Lukas Tribus" <luky...@hotmail.com> wrote: >> Hey Willy, >> >> Lukas explained it pretty well, but I can expound on it some more. >> >> You can imagine a situation where HAProxy has 2 certificates of >>different >> key types; one ECDSA and one RSA. In the current codebase, if no SNI is >> used, the certificate that is used will be whichever certificate is the >> default (i.e. the one that is first specified in the config). So we >>would >> have 2 possible paths: >> >> 1. ECDSA was specified first. This has the effect of only supporting >> cipher suites that has ECDSA. If the client does not support ECDSA, then >> it would mean that the connection will fail, even though the server has >>an >> RSA certificate. >> 2. RSA was specified first. This means that ECDSA cipher suites would >> never be used, which can decrease performance for initial handshakes as >> well as have a negative security impact. >> >> What I propose would address both of these issues. If the client prefers >> RSA or only supports RSA, then the RSA certificate is presented. >>However, >> if the client supports ECDSA, then we would use the ECDSA certificate. >> >> Lukas, >> I believe the reason that apache calls out 1.0.2 is this line in the >> OpenSSL (1.0.1l to 1.0.2a) changelog: >> >> * Add support for certificate stores in CERT structure. This makes it >> possible to have different stores per SSL structure or one store in the >> parent SSL_CTX. Include distint stores for certificate chain >>verification >> and chain building. New ctrl SSL_CTRL_BUILD_CERT_CHAIN to build and >>store >> a certificate chain in CERT structure: returing(sic) an error if the >>chain >> cannot be built: this will allow applications to test if a chain is >> correctly configured. >> >> In openssl <= 1.0.1, we can load multiple certs/keys into a single >> SSL_CTX. However, they must all have the same cert-chain. I believe that >> this 1.0.2 feature addresses this issue via certificate stores, and so >>can >> then use the existing s3server cipher suite selection code to select the >> correct certificate/key inside the library. This would alleviate the >>need >> to hook into a callback, which is what I¹m doing here. > >Does your code correctly handy ECC vs RSA intermediate certificates >in all cases? > > >Lukas > >
