> On Apr 8, 2024, at 5:44 AM, Theo Buehler <t...@theobuehler.org> wrote:
>
> 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
Did you create this certificate on OpenBSD with Libressl openssl? Or on linux
or something else with an OpenSSL openssl?
>
> 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
>>
>>
