Date: Mon, 1 Feb 2021 22:50:10 -0800 From: Benjamin Kaduk <kaduk@mit.edu> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org>, Jung-uk Kim <jkim@freebsd.org> Subject: Re: openssl in head returning "certificate expired" when it has not expired Message-ID: <20210202065010.GR21@kduck.mit.edu> In-Reply-To: <YQXPR0101MB0968E7E25E12A033A1CB4937DDB59@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> References: <YQXPR0101MB09681F6F58AE1EF74B5F6998DDB69@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <20210202004849.GJ21@kduck.mit.edu> <YQXPR0101MB0968E7E25E12A033A1CB4937DDB59@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 02, 2021 at 03:48:06AM +0000, Rick Macklem wrote: > Benjamin Kaduk wrote: > >On Tue, Feb 02, 2021 at 12:46:25AM +0000, Rick Macklem wrote: > >> I've recently been testing the daemons that do the > >> non-application data stuff for nfs-over-tls with the > >> openssl in head. > >> > >> These daemons work fine with both ports/security/openssl (openssl-1.1.1h) > >> and ports/security/openssl-devel (openssl3-alpha). > >> > >> However, when linked to the openssl in head, the basic handshake > >> and KTLS works, but the peer certificate from the client is reported > >> as expired by SSL_get_verify_result(), although it is still valid. > >> I added some debug output and the "notAfter" field of the > >> certificate looks correct, so the certificate doesn't seem to be > >> corrupted. > >> > >> I tried backporting the changes in crypto/x509 in head back > >> into ports/security/openssl and it still worked, so those changes > >> do not seem to have caused the problem. > >> There are several differences in the configured options, but I cannot > >> see any other differences between ports/security/openssl and > >> what is in head that could cause this. > >> (The options that differ seem related to old encryption types, etc.) > >> > >> Any other ideas for tracking this down? > > > >Is it perhaps related to https://github.com/openssl/openssl/issues/14036 ? > Well, it is definitely due to a change in behaviour between 1.1.1h and 1.1.1i. > I notices that ports/security/openssl has been upgraded to 1.1.1i and it > exhibits the "expired" behaviour. > > However, in my case, the certificate has not expired. > The notAfter date is in 2022, but SSL_get_verify_results() returns > X509_V_ERR_CERT_HAS_EXPIRED. Is there an expired CA in the chain? I suppose that reverting the commit from https://github.com/openssl/openssl/pull/11359 (linked from the issue) would probably be pretty easty to check. -Ben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210202065010.GR21>