Your message dated Thu, 31 May 2018 20:57:40 +0200 with message-id <[email protected]> and subject line Re: Bug#862335: openssl creates and accepts certificates with bad notAfter field has caused the Debian Bug report #862335, regarding openssl creates and accepts certificates with bad notAfter field to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 862335: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862335 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: openssl Version: 1.1.0e-1 If I create a self-signed certificate with a bad notAfter field, then openssl doesn't complain. Sample session: % mkdir -p ca/root-ca/private ca/root-ca/db crl certs % chmod 700 ca/root-ca/private % cp /dev/null ca/root-ca/db/root-ca.db % cp /dev/null ca/root-ca/db/root-ca.db.attr % echo 01 > ca/root-ca/db/root-ca.crt.srl % echo 01 > ca/root-ca/db/root-ca.crl.srl % % openssl req -new \ > -config etc/root-ca.conf \ > -out ca/root-ca.csr \ > -keyout ca/root-ca/private/root-ca.key Generating a 4096 bit RSA private key ...............................................++ ...........................................................................................................................................................................................++ writing new private key to 'ca/root-ca/private/root-ca.key' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- % openssl ca -selfsign \ > -config etc/root-ca.conf \ > -in ca/root-ca.csr \ > -out ca/root-ca.crt \ > -extensions root_ca_ext \ > -enddate 20451231235959Z Using configuration from etc/root-ca.conf Enter pass phrase for ./ca/root-ca/private/root-ca.key: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 1 (0x1) Validity Not Before: May 11 10:53:09 2017 GMT Not After : Dec 31 23:59:59 2045 GMT Subject: countryName = DE organizationName = example AG organizationalUnitName = example Certificate Authority commonName = example Root CA X509v3 extensions: X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: 57:E9:EC:EB:0A:A5:F4:26:DC:1A:CF:CE:2E:E5:59:20:F0:FE:10:AD Authority Information Access: CA Issuers - URI:http://pki.example.com/ca/root-ca.cer X509v3 CRL Distribution Points: Full Name: URI:http://pki.example.com/ca/root-ca.crl X509v3 Authority Key Identifier: keyid:57:E9:EC:EB:0A:A5:F4:26:DC:1A:CF:CE:2E:E5:59:20:F0:FE:10:AD Certificate is to be certified until Dec 31 23:59:59 2045 GMT (10461 days) Sign the certificate? [y/n]:yes 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated % openssl verify -CAfile ca/root-ca.crt ca/root-ca.crt ca/root-ca.crt: OK Please note the "-enddate 20451231235959Z" and compare with RFC 5280 section 4.1.2.5 (https://www.ietf.org/rfc/rfc5280.txt). The GeneralizedTime format is not allowed for 2045, but apparently openssl doesn't convert the string to UTCTime format. libressl rejects the certificate (created on Debian), e.g. on OpenBSD 6.0: % openssl verify -CAfile root-ca.crt root-ca.crt root-ca.crt: C = DE, O = example AG, OU = example Certificate Authority, CN = example Root CA error 14 at 0 depth lookup:format error in certificate's notAfter field Regards Harri
--- End Message ---
--- Begin Message ---Version: 1.1.1~~pre1-1 commit 04e62715db684d83bffac53793ff4cfac51e047a On 2017-05-15 09:29:42 [+0200], Harald Dunkel wrote: > Please don't underestimate this problem. openssl creates bad > certificates here without telling. It is *highly* annoying > if you are affected by a bad root certificate you already used > for setting up a private PKI and then detect the problem on > a platform with a better ssl implementation. > > I would highly appreciate if you could fix this for Stretch. As far as I can tell upstream did not push this into their 1.1.0 branch (if so please correct me). Therefore I would suggest that you convince upstream to push this patch into their 1.1.0 branch and then I could try to get this into Stretch. > Thanx > Harri Sebastian
--- End Message ---
