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. rick -Ben _______________________________________________ freebsd-current_at_freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Tue Feb 02 2021 - 02:48:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:27 UTC