From: Mischa Peters <openbsd@mlst.nl>
Subject: Re: LibreSSL changes in 7.5?
To: Theo Buehler <tb@theobuehler.org>
Cc: Tech <tech@openbsd.org>
Date: Sat, 6 Apr 2024 14:11:36 +0200



> On 6 Apr 2024, at 13:07, Theo Buehler <tb@theobuehler.org> wrote:
> 
> 
>> -----BEGIN CERTIFICATE-----
>> MIICPjCCAeSgAwIBAgIJAOy1+v/+I2WIMAoGCCqGSM49BAMCMDkxCzAJBgNVBAYT
>> Ak5MMRQwEgYDVQQKDAtQaGlsaXBzIEh1ZTEUMBIGA1UEAwwLcm9vdC1icmlkZ2Uw
>> IhgPMjAxNzAxMDEwMDAwMDBaGA8yMDM4MDExOTAzMTQwN1owPjELMAkGA1UEBhMC
>> TkwxFDASBgNVBAoMC1BoaWxpcHMgSHVlMRkwFwYDVQQDDBBlY2I1ZmFmZmZlMjM2
>> NTg4MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEAQMY8V0BUIhXtQfAwMPwqH+2
>> EyYnNCo9QhpPN93bJIWjppu0DyVUBzXY6rCyMD506mtSN4EsqH/3SHSPKnKD8KOB
>> yzCByDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggr
>> BgEFBQcDATAdBgNVHQ4EFgQU1s7ZbOFXYZSJLKhsXrPY072icg4wdAYDVR0jBG0w
>> a4AUZ2ONTFrDT6o8ItRnKfqWKnHFGmShPaQ7MDkxCzAJBgNVBAYTAk5MMRQwEgYD
>> VQQKDAtQaGlsaXBzIEh1ZTEUMBIGA1UEAwwLcm9vdC1icmlkZ2WCFDuxUi22sYpL
>> lwJY81Wrqy11phcOMAoGCCqGSM49BAMCA0gAMEUCIQCdQ2Sfn2t+OBGzDkB59OQO
>> 6YWwvJ66Q/VZoOyQaCsd3QIgNxpIOEJK3Tk3NTTfCkQOB+vTm285dgGNQ+5Ps3EL
>> Ni4=
>> -----END CERTIFICATE-----
> 
> This cert is malformed (as is the CA cert that sthen dug up).
> The notBefore and notAfter are before 2050:
> 
> $ openssl x509 -in /tmp/ku.pem -dates -noout
> notBefore=Jan  1 00:00:00 2017 GMT
> notAfter=Jan 19 03:14:07 2038 GMT
> 
> This means they should be encoded as UTCTime per RFC 5280. However,
> they are encoded as a GeneralizedTime:
> 
> $ openssl asn1parse -i -in /tmp/ku.pem | grep GEN
>  97:d=3  hl=2 l=  15 prim:    GENERALIZEDTIME   :20170101000000Z
> 114:d=3  hl=2 l=  15 prim:    GENERALIZEDTIME   :20380119031407Z
> 
> The cryptic error is unfortunate. As a consequence of the following
> commit, x509_verify_cert_info_populate() (which would silently cache
> nonsense previously) results in EXFLAG_INVALID being set on the cert's
> extension flags:
> 
> https://github.com/openbsd/src/commit/91b40737dd8713c4b24d6504eacee31f6b57e4c1
> 
> This in turn leads to an X509_get_key_usage() failure, which in turn
> leads to ssl_check_srvr_ecc_cert_and_alg() deciding the certificate
> is not for signing.
> 
> Since it is malformed, it is arguably not good for signing. I'm not
> sure whether 'ftp -S dont' should imply that the cert is completely
> ignored.

The fact it’s malformed doesn’t help. :(

I am seeing the same with Perl and Net-SSLeay, which was working on 7.4 and no longer on 7.5.

What would be the best course of action to take with destinations like this? Especially since I can’t control the other side.

Mischa