On Sun, Apr 07, 2024 at 04:57:24PM -0500, Ted Wynnychenko wrote:
> Hello,
>
> I recently updated to -current (about a week ago).
>
> I see that Libressl is at 3.9.1 just now, but I hope that won't be an issue
> (I did not see anything in the release notes that would impact my question).
> ---
> $ openssl version
> LibreSSL 3.9.0
> ---
>
> Over the years, I have made certificates for personal servers/resources on
> my home network. This is just for me, so I do some things that would be
> frowned on (although, technically, there is nothing "wrong" with them).
>
> In this case, since I have Apple iOS devices that I want to connect to
> https, I backdate any certificates I create to 1/2/2019. Apple has imposed
> a 300 or 800 day time limit on the validity for certificates created after
> (about) 7/1/2019. Since I don't want to constantly make new certificates
> for my personal/home network, I have just been setting the certificates'
> "not before" date to early 2019.
>
> Anyway, this had worked fine.
> In fact, earlier this year (Jan 2024), I created a new certificate, and all
> is good.
>
> A few weeks ago, I added a new thing to the network - a raspberry pi (I got
> as a gift about 2013 and installed a linux image from 2019 on it) that is
> connected to the home alarm system.
>
> Since I was annoyed that my browser was constantly giving me self-signed
> certificate warnings, I decided to make a certificate for the nginx running
> on this appliance.
>
> I created a key, made a csr, and then signed it with:
> openssl ca -startdate 20190102000000Z -in pi.csr -out pi.pem -config
> /etc/ssl/openssl.cnf
As a workaround, try using '-startdate 190102000000Z' instead. I think
this is fallout from this commit:
https://github.com/openbsd/src/commit/3feee4c53fbd67a4a480080d8ef5ae835d3fbf82
ASN1_TIME_set_string_X509() is documented as
In LibreSSL, ASN1_TIME_set_string() and ASN1_TIME_set_string_X509()
behave identically and always set the time object to a valid value to use
in an X.509 certificate.
It seems to me that this is just wrong (it is true that both behave
identically because RFC5280 is defined to 0), but they do not set the
time object to "a valid value to use in an X.509 certificate".
Confusingly, ASN1_TIME_adj_internal() actually honours its RFC5280
parameter by behaving the expected way whereas its meaning in
ASN1_TIME_set_string_internal() is different.
I am unsure if the bug is in my commit above or in our version of
ASN1_TIME_set_string_X509() (or both).
>
> This all works fine, and a certificate is created
>
> When I check with:
> openssl x509 -text -noout -in pi.pem
>
> everything seems as expected, including the not before/after dates:
>
> Validity
> Not Before: Jan 2 00:00:00 2019 GMT
> Not After : Apr 7 15:39:59 2054 GMT
>
> (yes, it is valid for 35 years - as I said before, if someone breaks into my
> house to secretly do things, I have way bigger problems)
>
> But, if I try to verify this on the openbsd system, I get:
>
> # openssl verify pi.pem
> C = US, ST = Illinois, L = ***, O = ***, OU = ***, CN = ***
> error 20 at 0 depth lookup:unable to get local issuer certificate
> pi.pem: verification failed: 20 (unable to get local issuer certificate)
> ---
>
> But, if I install this on the raspberry pi, which has a much older version
> of openssl on it:
> $ openssl version
> OpenSSL 1.1.1c 28 May 2019
>
> The certificate verifies without an issue:
> $ openssl verify pi.pem
> pi.pem: OK
>
> The last time I created a certificate was in January of this year
> (1/22/2024).
> I am thinking the openbsd system was using Libressl 3.8.2 at that point.
>
> I created that certificate in the exact same way, backdating the start date:
> openssl ca -startdate 20190102000000Z -in 54.csr -out 54.pem -config
> /etc/ssl/openssl.cnf
>
> This previously created certificate also has them same backdated and very
> long valid period:
>
> Validity
> Not Before: Jan 2 00:00:00 2019 GMT
> Not After : Jan 21 23:49:22 2054 GMT
>
> (Notice the not after date is a little different)
> Today, with the new libressl, this certificate verifies OK.
>
> $ openssl verify 54.pem
> 54.pem: OK
>
> Finally, if I create the new certificate WITHOUT backdating it
> e.g.: openssl ca -in pi.csr -out pi.pem -config /etc/ssl/openssl.cnf
>
> The certificate is created and verifies OK.
>
> So, it seems, there is some sort of issue with backdating the certificate,
> but not an issue with the crazy long validity window, that was not present
> in January of this year.
>
> However, as I said, if I don't backdate, then in about a year the ipad will
> refuse to connect because of the restrictions apple has imposed, unless I
> update the certificate.
>
> I know this is not "best practice," but it should still work, right?
>
> Is there something I am missing?
> Otherwise, it appears something has changed in Libressl 3.9.0 but is not
> documented.
>
> Thanks in advance for any suggestions.
> Ted
>
>
No comments:
Post a Comment