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 - 0s 0s ---- peer not valid ---- > > 37.187.104.44 from pool pool.ntp.org > > 1 2 - 0s 0s ---- peer not valid ---- > > 37.187.2.84 from pool pool.ntp.org > > 1 2 - 0s 0s ---- peer not valid ---- > > 163.172.163.169 from pool pool.ntp.org > > 1 2 - 0s 0s ---- 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 <s...@spacehopper.org> ----- From: Stuart Henderson <s...@spacehopper.org> Date: Mon, 2 Jan 2017 13:26:07 +0000 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 2802 and 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 be preferable? - re-add the removed CAs to cert.pem - revert the callback in libtls, which would fix things with ftp/nc but not other programs like curl ----- End forwarded message -----
