Thanks for the suggestion.
The workaround does work, and creates (essentially) the same certificate,
but one that does not fail verification with the new libressl.
I did notice the option of not have the leading "20" for dates before 2050,
but I did not know enough to try doing that.
Ted
> -----Original Message-----
> > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On
> Behalf
> > Of Theo Buehler
> > Sent: Monday, April 08, 2024 6:45 AM
> > To: Ted Wynnychenko
> > Cc: 'OpenBSD misc'; b...@openbsd.org; js...@openbsd.org
> > Subject: Re: Libressl verify failure with 3.9.0
> >
> > 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/3feee4c53fbd67a4a480080d8ef5ae835
> > d3fbf82
> >
> > 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
> > >
> > >
