[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 I’ve 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, I’ve 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 doesn’t appear to be able to use the intermediate CA provided by the server in the verification. Here’s what I see when the client trusts only the root CA:
>> 
>> [SNIP]
>> However, when I add the intermediate CA to the client’s X509 store, it succeeds:
>> 
>> [SNIP]
>> 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 there’s a certificate count of 2 and an OCSP response count of 2).
>> 
>> Any idea what I might be doing wrong that’s 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
      sender.

   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?
-- 
Ron Frederick
ronf at timeheart.net





More information about the ssh_x509 mailing list