Date: Tue, 2 Feb 2021 15:13:43 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Benjamin Kaduk <kaduk@mit.edu> 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: <YQXPR0101MB09682CAA6C302C6F616FA98EDDB59@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <20210202065010.GR21@kduck.mit.edu> References: <YQXPR0101MB09681F6F58AE1EF74B5F6998DDB69@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <20210202004849.GJ21@kduck.mit.edu> <YQXPR0101MB0968E7E25E12A033A1CB4937DDB59@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>, <20210202065010.GR21@kduck.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Benjamin Kaduk wrote:=0A= >On Tue, Feb 02, 2021 at 03:48:06AM +0000, Rick Macklem wrote:=0A= >> Benjamin Kaduk wrote:=0A= >> >On Tue, Feb 02, 2021 at 12:46:25AM +0000, Rick Macklem wrote:=0A= >> >> I've recently been testing the daemons that do the=0A= >> >> non-application data stuff for nfs-over-tls with the=0A= >> >> openssl in head.=0A= >> >>=0A= >> >> These daemons work fine with both ports/security/openssl (openssl-1.1= .1h)=0A= >> >> and ports/security/openssl-devel (openssl3-alpha).=0A= >> >>=0A= >> >> However, when linked to the openssl in head, the basic handshake=0A= >> >> and KTLS works, but the peer certificate from the client is reported= =0A= >> >> as expired by SSL_get_verify_result(), although it is still valid.=0A= >> >> I added some debug output and the "notAfter" field of the=0A= >> >> certificate looks correct, so the certificate doesn't seem to be=0A= >> >> corrupted.=0A= >> >>=0A= >> >> I tried backporting the changes in crypto/x509 in head back=0A= >> >> into ports/security/openssl and it still worked, so those changes=0A= >> >> do not seem to have caused the problem.=0A= >> >> There are several differences in the configured options, but I cannot= =0A= >> >> see any other differences between ports/security/openssl and=0A= >> >> what is in head that could cause this.=0A= >> >> (The options that differ seem related to old encryption types, etc.)= =0A= >> >>=0A= >> >> Any other ideas for tracking this down?=0A= >> >=0A= >> >Is it perhaps related to https://github.com/openssl/openssl/issues/1403= 6 ?=0A= >> Well, it is definitely due to a change in behaviour between 1.1.1h and 1= .1.1i.=0A= >> I notices that ports/security/openssl has been upgraded to 1.1.1i and it= =0A= >> exhibits the "expired" behaviour.=0A= >>=0A= >> However, in my case, the certificate has not expired.=0A= >> The notAfter date is in 2022, but SSL_get_verify_results() returns=0A= >> X509_V_ERR_CERT_HAS_EXPIRED.=0A= >=0A= >Is there an expired CA in the chain?=0A= Ouch, yes that's it. The root CA has expired.=0A= =0A= >I suppose that reverting the commit from=0A= >https://github.com/openssl/openssl/pull/11359 (linked from the issue) woul= d=0A= >probably be pretty easty to check.=0A= I replaced x509_vfy.c with the one from openssl-1.1.1h and the problem went= =0A= away. (which I suspect is about the same thing)=0A= =0A= Now I'll go and create a new root CA, etc and make sure it works with=0A= openssl-1.1.1i and what is in head.=0A= =0A= Thanks for the helpful comments, rick=0A= =0A= -Ben=0A= =0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR0101MB09682CAA6C302C6F616FA98EDDB59>