Bug#862335: closed by Sebastian Andrzej Siewior (Re: Bug#862335: openssl creates and accepts certificates with bad notAfter field)

[Harald Dunkel]

It has been fixed in libressl and openssl 1.1.1, so I am fine. I rely
upon your expertise that the problem doesn't have to be fixed in 1.1.0.

Thanx for your support
Harri

Bug#862335: openssl creates and accepts certificates with bad notAfter field

[Harald Dunkel]

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.


Thanx
Harri

Bug#862335: openssl creates and accepts certificates with bad notAfter field

[Tim Rühsen]

On Thu, 11 May 2017 18:42:17 +0200 Kurt Roeckx  wrote:
> On Thu, May 11, 2017 at 02:59:20PM +0200, Harald Dunkel wrote:
>> 
>> 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.
> 
> Please note that the manual says the format is: YYMMDDHHMMSSZ
> 
> I guess it would be nice we converted it properly.

Just for the record, the latest openssl (1.1.1-dev from Github) accepts
this (seen from the code):

[SS] is optional, <+|-> = either + or - must be present

1.
YYMMDDHHMM[SS]Z YYMMDDHHMM[SS]<+|->hhmm
If valid, these date strings are written to ASN.1 into an UTCTime field.

2.
MMDDHHMM[SS]Z or MMDDHHMMSS<+|->hhmm
If valid, these date strings are written to ASN.1 into a GeneralizedTime
field.

Regarding RFC5280 in both cases (UTCTime and GeneralizedTime) the
seconds (SS) and Z (Zulu) timezone is a MUST.

See RFC5280 '4.1.2.5.1.  UTCTime' and '4.1.2.5.2.  GeneralizedTime'.

OpenSSL relies on their ASN.1 code to check for validity, which is
simply not strict enough. Other implementors do a strict check and thus
might reject certificates generated by openssl.

Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#862335: [Pkg-openssl-devel] Bug#862335: openssl creates and accepts certificates with bad notAfter field

[Kurt Roeckx]

On Thu, May 11, 2017 at 02:59:20PM +0200, Harald Dunkel wrote:
> 
> 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.

Please note that the manual says the format is: YYMMDDHHMMSSZ

I guess it would be nice we converted it properly.


Kurt

Bug#862335: openssl creates and accepts certificates with bad notAfter field

[Harald Dunkel]

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