Re: Libressl verify failure with 3.9.0
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 2019010200Z -in pi.csr -out pi.pem - > config > > > /etc/ssl/openssl.cnf > > > > As a workaround, try using '-startdate 19010200Z' 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
Re: Libressl verify failure with 3.9.0
On Mon, Apr 08, 2024 at 05:53:47PM -0500, Ted Wynnychenko wrote: > 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. Great. openssl ca should be smart enough to do that for you. It tried to, but failed due to a bug. This will be fixed in the next release: https://github.com/openbsd/src/commit/72c7c57a68e32c57ac752161b5a93464ad11e7e1 The incomprehensible verification error is another bug and that will also be fixed.
Re: Libressl verify failure with 3.9.0
> On Apr 8, 2024, at 5:44 AM, Theo Buehler 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 2019010200Z -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 19010200Z' 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 2019010200Z -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
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 2019010200Z -in pi.csr -out pi.pem -config > /etc/ssl/openssl.cnf As a workaround, try using '-startdate 19010200Z' 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 2019010200Z -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
Libressl verify failure with 3.9.0
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 2019010200Z -in pi.csr -out pi.pem -config /etc/ssl/openssl.cnf 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 2019010200Z -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
