On 2017/01/02 16:37, Matthieu Herrb wrote:
> On Mon, Jan 02, 2017 at 03:59:51PM +0100, Matthieu Herrb wrote:
> > Hi,
> >
> > running -current on amd64 and i386 with the default /etc/ntpd.conf,
> > ntpd doesn't send any NTP request and doesn't sync the clock...
> >
> > mirrorball% ntpctl -sa
> > 0/4 peers valid, clock unsynced
> >
> > peer
> >wt tl st next poll offset delay jitter
> > 151.80.19.218 from pool pool.ntp.org
> > 1 2 -0s0s peer not valid
> > 37.187.104.44 from pool pool.ntp.org
> > 1 2 -0s0s peer not valid
> > 37.187.2.84 from pool pool.ntp.org
> > 1 2 -0s0s peer not valid
> > 163.172.163.169 from pool pool.ntp.org
> > 1 2 -0s0s peer not valid
> >
> > tcpdump -n -i em0 port 123 doesn't show any trafic on ntp port
> >
>
> Looking a bit more, this is caused by a cert validation failure during
> constraints checks.
> The www.google.com certificate fails verification because the 'Equifax
> Secure Certificate Authority' root CA certificate that is on top of
> the www.google.com certificate chain is missing from newer
> /etc/ssl/cert.pem.
It fails verification because alt chains aren't working correctly.
It's this problem which I mentioned on another list:
- Forwarded message from Stuart Henderson -
From: Stuart Henderson
Date: Mon, 2 Jan 2017 13:26:07 +
Subject: alt chains / verify callback [Re: CVS: cvs.openbsd.org: src]
On 2016/12/26 09:20, Joel Sing wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: js...@cvs.openbsd.org 2016/12/26 09:20:58
>
> Modified files:
> lib/libtls : tls.c tls_client.c
>
> Log message:
> Hook up a certificate verify callback so that we can set user friendly
> error messages, instead of libssl error strings. This gives us messages
> like:
>
> certificate verification failed: certificate has expired
>
> Instead of:
>
> 14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>
> This also lets us always enable peer verification since the no verification
> case is now handled via the callback.
>
> Tested by tedu@
>
> ok beck@
>
naddy ran into a problem fetching ports distfiles from a google server
with ftp(1) with the new cert.pem, whereas it was working OK for me
when I tested the cert.pem update with ftp(1) on a slightly older
snapshot (23 Dec).
I've bisected and found that this was the commit that stopped it from
working. However testing further I find that curl(1) (which doesn't
use libtls) also fails in a similar way.
google's chain looks like this;
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
With the new cert.pem the old 1024-bit "Equifax Secure Certificate Authority"
cert is no longer included, so alt chains need to work to be able to connect to
it (GeoTrust Global CA is in cert.pem).
On -current:
$ nc -vvc google.com 443
Connection to google.com 443 port [tcp/https] succeeded!
nc: tls handshake failed (certificate verification failed: certificate not
trusted)
On a machine with new cert.pem but older libtls:
$ ssh jodrell nc -vvc google.com 443
Connection to google.com 443 port [tcp/https] succeeded!
TLS handshake negotiated TLSv1.2/ECDHE-ECDSA-CHACHA20-POLY1305 with host
google.com
Peer name: google.com
Subject: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
Issuer: /C=US/O=Google Inc/CN=Google Internet Authority G2
Valid From: Thu Dec 15 14:04:15 2016
Valid Until: Thu Mar 9 13:35:00 2017
Cert Hash:
SHA256:c6ad71b8ad015bff4df56886261d0f975caa3ae427a3e68c2f8bf92f36824d4b
OCSP URL: http://clients1.google.com/ocsp
And on either machine with curl:
$ curl https://www.google.com/
curl: (51) SSL certificate verify result: certificate not trusted (27)
curl is not using SSL_CTX_set_cert_verify_callback; in that case the failure
is coming from SSL_get_verify_result -
lib/vtls/openssl.c
2796 lerr = data->set.ssl.certverifyresult =
2797 SSL_get_verify_result(connssl->handle);
2798
2799 if(data->set.ssl.certverifyresult != X509_V_OK) {
2800 if(data->set.ssl.verifypeer) {
2801 /* We probably never reach this, because SSL_connect() will fail
2802and we return earlier if verifypeer is set? */
2803 if(strict)
2804 failf(data, "SSL certificate verify result: %s (%ld)",
2805 X509_verify_cert_error_string(lerr), lerr);
2806 result = CURLE_PEER_FAILED_VERIFICATION;
2807 }
Does anyone have ideas to fix it? If not, which of the temporary workarounds
would