Chain CA fails with 1.2.6

benjy

Hi,

Since 1.2.6 it seems the chain CA validation is broken.
Our infra is a bit particular as we have two differents CA
Server: CA1 -> subCA1 -> Sub-subCA1 -> server cert
Clients: CA2 -> subCA2 -> Sub-subCA2 -> client cert

The server includes CA2 in addition to the CA1 chain in its CA file to validate our clients.
The clients include CA1 in addition to the CA2 chain in its CA file as well.

All works for windows/linux/OSX/Android clients. But it fails for IOS since 1.2.6 (and maybe 1.2.5), it was working before though.

The server log shows that if fails to check the client chain:

VERIFY ERROR: depth=0, error=unable to get local issuer certificate: OU=OpenVPN-Mobile, CN=xxx

I tried different combination to include in the client CA but it never manages to get the local issuer.

Should I fill a bug report for this?
Apologies if it has been reported already.

Thanks,
Ben

ordex

benjy wrote All works for windows/linus/OSX/Android clients. But it fails for IOS since 1.2.6 (ans maybe 1.2.5), it was working before though.

Do you know if this works on linux when using mbedtls 2.6 as cryptolibrary ? (the latter is especially important)

edit: it's interesting though that it's the server to report the cert issue..

benjy

It fails with mbedtls 2.6 but for a different reason, it fails on the client side to verify the server CA:

VERIFY OK: depth=3 XXXX
VERIFY ERROR: depth=2 XXXX: The certificate is signed with an unacceptable hash.
VERIFY ERROR: depth=1 XXX: The certificate is signed with an unacceptable hash.

I would say it's because those CA are still signed with SHA1, however the first CA is OK while also with SHA1 so i'm not sure.

I tested with mbed TLS 2.2.1 as well and with this version it fails the same way as the IOS app ie:

VERIFY ERROR: depth=0, error=unable to get local issuer certificate: OU=OpenVPN-Mobile, CN=xxx

in the server logs.

But all is fine with OpenSSL 1.0.2g

dazo

This begins to smell like the hardening the mbed TLS project have added to mbedtls-2.6.x. We have tried to take some steps making mbed TLS a bit more forgiving to those SHA1 certificates, though. But what about the private key length how long is that?

It's a shot in the dark, mostly because my memory is vague, but try to add --tls-cert-profile legacy to the client configuration.

benjy

I see, so --tls-cert-profile legacy wasn't supported with the current openvpn 2.4.4
I tried from the current github master, it also fails the same way this time with or without --tls-cert-profile legacy. It fails on the server side as before.

It fails on the client side with --tls-cert-profile preferred or suiteb.
With that openvpn version (2.5 from git) I don't get the "unacceptable hash" warning by default, I get it only with "--tls-cert-profile suiteb"

I don't have access to the private key right now but I assume it should be 2048 bits.

dazo

If the key is 2048 bits, you should be good. But it's enough to look at the certificate. Try: openssl x509 -noout -text -in $CERT | grep Public-Key:

But check all CA certificates as well as client and server certs.

Other wise, odd that suiteb is the only one removing this warning ... that is even stricter than 'preferred'.

benjy

Ok thanks, the CA keys are actually all 4096 bits after checking. Client and server keys are 2048 bits.

But otherwise suiteb does gives me the hash warning and fails on the client side. It's the only one that gives it, legacy and preferred don't, so I guess it's expected but it doesn't explain why they still fail on the server side to check the client chain though.

benjy

Should I create a bug report for this one?

dazo

Sorry for dropping the ball. We've submitted a few more updates since the 1.2.6 release. Do you still see the same issues with the latest one? If so, then it would be good to file a bug report with much more details. If you can manage to create a new set (for testing only!) of CA certificate, server and client keys+certs and upload it with the bug report, that can help us inspect what is happening - which will improve the time it takes to figure it out and getting a fix out if needed.