[ssh_x509] Validating host with certificate chain
ssh_x509 at roumenpetrov.info
ssh_x509 at roumenpetrov.info
Tue May 16 06:04:09 EEST 2017
On May 15, 2017, at 12:09 PM, ssh_x509 at roumenpetrov.info wrote:
> Thanks for report .
> ssh_x509 at roumenpetrov.info wrote:
>> I recently installed pkixssh 10.1.1. It built fine and Ive managed to do a successful key exchange with it using an RSA host key and X509 RSA certificate that I generated myself, chained through an intermediate CA to a private root CA. However, so far, Ive only been able to get this to work when I provide the client with both the root CA and the intermediate CA in its X509 store. If I provided only the root CA on the client, the validation fails, even though I have configured the server to send a certificate chain which includes both a server certificate for the host and the intermediate CA.
>> Looking at the debug messages on the client, it appears to be receiving two certificates from the server during the key exchange, but it doesnt appear to be able to use the intermediate CA provided by the server in the verification. Heres what I see when the client trusts only the root CA:
>> However, when I add the intermediate CA to the clients X509 store, it succeeds:
>> In both cases, the server is sending the server certificate and intermediate CA (as you can see in the debug output at the top where theres a certificate count of 2 and an OCSP response count of 2).
>> Any idea what I might be doing wrong thats preventing the client from using the intermediate CA provided by the server?
> Unfortunately it is mistake in code - certificates from key are not passed to verification routine.
> It is corrected by attached patch "0004-pass-key-chain-with-X.509-certificates-to-verify-met.patch”.
Thanks very much for the quick fix, Roumen! I’ve applied the patch, and the validation is now working with only the root CA being provided on the client!
Does pkixssh do the other validations mentioned in RFC 6187? In particular, I’m thinking about:
Additionally, the following constraints apply:
o The sender's certificate MUST be the first certificate and the
public key conveyed by this certificate MUST be consistent with
the public key algorithm being employed to authenticate the
o Each following certificate MUST certify the one preceding it.
o The self-signed certificate specifying the root authority MAY be
omitted. All other intermediate certificates in the chain leading
to a root authority MUST be included.
I did a quick test and it looks like it enforces the first constraint on the server side when first loading the keys, but I’m not sure if it enforces this on the client side.
The second point doesn’t appear to be enforced on either side right now. I tried adding an unrelated cert into the middle of the list of certificates and the server didn’t error out. It sent all 3 certificates to the client, and the client still validated the chain just fine, despite the extra certificate not certifying the one before it, or being certified by the certificate after it.
The third point is also not enforced. If I provide only the server certificate and no intermediate CA in the server’s private key file but I add both the intermediate CA and the root CA into the client’s X509 store, the validation succeeds.
Also, do you do validation of the OCSP responses included with the certificates?
ronf at timeheart.net
More information about the ssh_x509