OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Wolfgang Knauf

Hi,

 

I first asked this question in the OpenVPNGui forum, and they redirected me to here: OpenVPNGui 2.4.6 works with a customers server certificate, but it fails when using 2.4.7.

 

Here is the thread in the OpenVPNGui forum: https://forums.openvpn.net/viewtopic.php?f=24&t=27976

 

The error is:

Thu Feb 28 08:48:50 2019 VERIFY ERROR: depth=0, error=format error in certificate's notAfter field: C=de, L=Dortmund, O=Versatel, CN=ASG_1, emailAddress=...

 

The certificate has those fields:

        Validity

            Not Before: Oct 22 13:28:29 2009 GMT

            Not After : Mar  8 13:28:29 2037 GMT

 

The customer provided us with a „…..ca.crt“ file, a „….user.crt“ file and a „user.key“ file. But I fear it is not smart to post those files in the internet ;-).

 

Best regards

 

Wolfgang

Reply | Threaded
Open this post in threaded view
|

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Richard Levitte - VMS Whacker-2
The format error refers to how the numbers are encoded in the
certificate.  The best way to see for ourselves is if you can run
'openssl asn1parse' on the certificate and show us the sequence that
contains the notBefore and notAfter time-stamps.  The are seen
together between the issuer name and the subject name.

As an example, here's the 'openssl asn1parse' output for
test/testx509.pem:

    : ; openssl asn1parse -i -in test/testx509.pem
        0:d=0  hl=4 l= 347 cons: SEQUENCE          
        4:d=1  hl=4 l= 262 cons:  SEQUENCE          
        8:d=2  hl=2 l=   1 prim:   INTEGER           :18
       11:d=2  hl=2 l=  13 cons:   SEQUENCE          
       13:d=3  hl=2 l=   9 prim:    OBJECT            :md5WithRSAEncryption
       24:d=3  hl=2 l=   0 prim:    NULL              
       26:d=2  hl=2 l=  56 cons:   SEQUENCE          
       28:d=3  hl=2 l=  11 cons:    SET              
       30:d=4  hl=2 l=   9 cons:     SEQUENCE          
       32:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
       37:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :AU
       41:d=3  hl=2 l=  12 cons:    SET              
       43:d=4  hl=2 l=  10 cons:     SEQUENCE          
       45:d=5  hl=2 l=   3 prim:      OBJECT            :stateOrProvinceName
       50:d=5  hl=2 l=   3 prim:      PRINTABLESTRING   :QLD
       55:d=3  hl=2 l=  27 cons:    SET              
       57:d=4  hl=2 l=  25 cons:     SEQUENCE          
       59:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
       64:d=5  hl=2 l=  18 prim:      PRINTABLESTRING   :SSLeay/rsa test CA
       84:d=2  hl=2 l=  30 cons:   SEQUENCE          
       86:d=3  hl=2 l=  13 prim:    UTCTIME           :950619233312Z
      101:d=3  hl=2 l=  13 prim:    UTCTIME           :950717233312Z
      116:d=2  hl=2 l=  58 cons:   SEQUENCE          
      118:d=3  hl=2 l=  11 cons:    SET              
      120:d=4  hl=2 l=   9 cons:     SEQUENCE          
      122:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
      127:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :AU
      131:d=3  hl=2 l=  12 cons:    SET              
      133:d=4  hl=2 l=  10 cons:     SEQUENCE          
      135:d=5  hl=2 l=   3 prim:      OBJECT            :stateOrProvinceName
      140:d=5  hl=2 l=   3 prim:      PRINTABLESTRING   :QLD
      145:d=3  hl=2 l=  29 cons:    SET              
      147:d=4  hl=2 l=  27 cons:     SEQUENCE          
      149:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
      154:d=5  hl=2 l=  20 prim:      PRINTABLESTRING   :SSLeay/rsa test cert
      176:d=2  hl=2 l=  92 cons:   SEQUENCE          
      178:d=3  hl=2 l=  13 cons:    SEQUENCE          
      180:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
      191:d=4  hl=2 l=   0 prim:     NULL              
      193:d=3  hl=2 l=  75 prim:    BIT STRING        
      270:d=1  hl=2 l=  12 cons:  SEQUENCE          
      272:d=2  hl=2 l=   8 prim:   OBJECT            :md5
      282:d=2  hl=2 l=   0 prim:   NULL              
      284:d=1  hl=2 l=  65 prim:  BIT STRING        

Here, the notBefore and notAfter are the following lines:

       84:d=2  hl=2 l=  30 cons:   SEQUENCE          
       86:d=3  hl=2 l=  13 prim:    UTCTIME           :950619233312Z
      101:d=3  hl=2 l=  13 prim:    UTCTIME           :950717233312Z

For visualization, this is the text form output of the same:

    : ; openssl x509 -in test/testx509.pem -dates -noout
    notBefore=Jun 19 23:33:12 1995 GMT
    notAfter=Jul 17 23:33:12 1995 GMT

So now, for the encoding, RFC5280 has a few things to say
(https://tools.ietf.org/html/rfc5280#section-4.1.2.5).  However, for
the dates you display, it should be easy, the should be the following:

    UTCTIME :091022132829Z
    UTCTIME :370308132829Z

If you see something violently different (such as GeneralizedTime
instead of UTCTIME), or the number of digits being wrong (12 for
UTCTIME, 14 for GeneralizedTime), or there being something other than
'Z' at the end, then you know why you get that error.

(I encoded those numbers manually, so I hope I got them right)

Cheers,
Richard

On Mon, 04 Mar 2019 09:08:30 +0100,
Wolfgang Knauf wrote:

>
>
> Hi,
>
> I first asked this question in the OpenVPNGui forum, and they redirected me to here: OpenVPNGui
> 2.4.6 works with a customers server certificate, but it fails when using 2.4.7.
>
> Here is the thread in the OpenVPNGui forum: https://forums.openvpn.net/viewtopic.php?f=24&t=27976
>
> The error is:
>
> Thu Feb 28 08:48:50 2019 VERIFY ERROR: depth=0, error=format error in certificate's notAfter field
> : C=de, L=Dortmund, O=Versatel, CN=ASG_1, emailAddress=...
>
> The certificate has those fields:
>
>         Validity
>
>             Not Before: Oct 22 13:28:29 2009 GMT
>
>             Not After : Mar  8 13:28:29 2037 GMT
>
> The customer provided us with a „…..ca.crt“ file, a „….user.crt“ file and a „user.key“ file. But I
> fear it is not smart to post those files in the internet ;-).
>
> Best regards
>
> Wolfgang
>
>
--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
Reply | Threaded
Open this post in threaded view
|

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Jan Just Keijser-2
In reply to this post by Wolfgang Knauf
Hi,

On 04/03/19 09:08, Wolfgang Knauf wrote:

Hi,

 

I first asked this question in the OpenVPNGui forum, and they redirected me to here: OpenVPNGui 2.4.6 works with a customers server certificate, but it fails when using 2.4.7.

 

Here is the thread in the OpenVPNGui forum: https://forums.openvpn.net/viewtopic.php?f=24&t=27976

 

The error is:

Thu Feb 28 08:48:50 2019 VERIFY ERROR: depth=0, error=format error in certificate's notAfter field: C=de, L=Dortmund, O=Versatel, CN=ASG_1, emailAddress=...

 

The certificate has those fields:

        Validity

            Not Before: Oct 22 13:28:29 2009 GMT

            Not After : Mar  8 13:28:29 2037 GMT

 

The customer provided us with a „…..ca.crt“ file, a „….user.crt“ file and a „user.key“ file. But I fear it is not smart to post those files in the internet ;-).

 


you can safely post the client.crt file - it is public info and useless without the key file. 

Having said that, I just created a certificate set to expire on Mar 9 2037 and it passed the following command:
  c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in mycert.crt

can you run the same command on the failing certificate?

HTH,

JJK / Jan Just Keijser

Reply | Threaded
Open this post in threaded view
|

AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Wolfgang Knauf
In reply to this post by Richard Levitte - VMS Whacker-2
Hi,

the output is this:

C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in ..\config\[hidden email]\l1139218.vt-security.de.user.crt
Error: offset too large

Would it be OK if I send the crt file to only your mail adress? I don't feel save by posting it to the mailing list ;-)?

I did not try to convert the date - still have the hope that it is an OpenSSL issue and can be fixed there ;-).

Best regards

Wolfgang

 
-----Ursprüngliche Nachricht-----
Von: openssl-users <[hidden email]> Im Auftrag von Richard Levitte
Gesendet: Montag, 4. März 2019 10:02
An: [hidden email]
Betreff: Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

The format error refers to how the numbers are encoded in the certificate.  The best way to see for ourselves is if you can run 'openssl asn1parse' on the certificate and show us the sequence that contains the notBefore and notAfter time-stamps.  The are seen together between the issuer name and the subject name.

As an example, here's the 'openssl asn1parse' output for
test/testx509.pem:

    : ; openssl asn1parse -i -in test/testx509.pem
        0:d=0  hl=4 l= 347 cons: SEQUENCE          
        4:d=1  hl=4 l= 262 cons:  SEQUENCE          
        8:d=2  hl=2 l=   1 prim:   INTEGER           :18
       11:d=2  hl=2 l=  13 cons:   SEQUENCE          
       13:d=3  hl=2 l=   9 prim:    OBJECT            :md5WithRSAEncryption
       24:d=3  hl=2 l=   0 prim:    NULL              
       26:d=2  hl=2 l=  56 cons:   SEQUENCE          
       28:d=3  hl=2 l=  11 cons:    SET              
       30:d=4  hl=2 l=   9 cons:     SEQUENCE          
       32:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
       37:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :AU
       41:d=3  hl=2 l=  12 cons:    SET              
       43:d=4  hl=2 l=  10 cons:     SEQUENCE          
       45:d=5  hl=2 l=   3 prim:      OBJECT            :stateOrProvinceName
       50:d=5  hl=2 l=   3 prim:      PRINTABLESTRING   :QLD
       55:d=3  hl=2 l=  27 cons:    SET              
       57:d=4  hl=2 l=  25 cons:     SEQUENCE          
       59:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
       64:d=5  hl=2 l=  18 prim:      PRINTABLESTRING   :SSLeay/rsa test CA
       84:d=2  hl=2 l=  30 cons:   SEQUENCE          
       86:d=3  hl=2 l=  13 prim:    UTCTIME           :950619233312Z
      101:d=3  hl=2 l=  13 prim:    UTCTIME           :950717233312Z
      116:d=2  hl=2 l=  58 cons:   SEQUENCE          
      118:d=3  hl=2 l=  11 cons:    SET              
      120:d=4  hl=2 l=   9 cons:     SEQUENCE          
      122:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
      127:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :AU
      131:d=3  hl=2 l=  12 cons:    SET              
      133:d=4  hl=2 l=  10 cons:     SEQUENCE          
      135:d=5  hl=2 l=   3 prim:      OBJECT            :stateOrProvinceName
      140:d=5  hl=2 l=   3 prim:      PRINTABLESTRING   :QLD
      145:d=3  hl=2 l=  29 cons:    SET              
      147:d=4  hl=2 l=  27 cons:     SEQUENCE          
      149:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
      154:d=5  hl=2 l=  20 prim:      PRINTABLESTRING   :SSLeay/rsa test cert
      176:d=2  hl=2 l=  92 cons:   SEQUENCE          
      178:d=3  hl=2 l=  13 cons:    SEQUENCE          
      180:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
      191:d=4  hl=2 l=   0 prim:     NULL              
      193:d=3  hl=2 l=  75 prim:    BIT STRING        
      270:d=1  hl=2 l=  12 cons:  SEQUENCE          
      272:d=2  hl=2 l=   8 prim:   OBJECT            :md5
      282:d=2  hl=2 l=   0 prim:   NULL              
      284:d=1  hl=2 l=  65 prim:  BIT STRING        

Here, the notBefore and notAfter are the following lines:

       84:d=2  hl=2 l=  30 cons:   SEQUENCE          
       86:d=3  hl=2 l=  13 prim:    UTCTIME           :950619233312Z
      101:d=3  hl=2 l=  13 prim:    UTCTIME           :950717233312Z

For visualization, this is the text form output of the same:

    : ; openssl x509 -in test/testx509.pem -dates -noout
    notBefore=Jun 19 23:33:12 1995 GMT
    notAfter=Jul 17 23:33:12 1995 GMT

So now, for the encoding, RFC5280 has a few things to say (https://tools.ietf.org/html/rfc5280#section-4.1.2.5).  However, for the dates you display, it should be easy, the should be the following:

    UTCTIME :091022132829Z
    UTCTIME :370308132829Z

If you see something violently different (such as GeneralizedTime instead of UTCTIME), or the number of digits being wrong (12 for UTCTIME, 14 for GeneralizedTime), or there being something other than 'Z' at the end, then you know why you get that error.

(I encoded those numbers manually, so I hope I got them right)

Cheers,
Richard

On Mon, 04 Mar 2019 09:08:30 +0100,
Wolfgang Knauf wrote:

>
>
> Hi,
>
> I first asked this question in the OpenVPNGui forum, and they
> redirected me to here: OpenVPNGui
> 2.4.6 works with a customers server certificate, but it fails when using 2.4.7.
>
> Here is the thread in the OpenVPNGui forum:
> https://forums.openvpn.net/viewtopic.php?f=24&t=27976
>
> The error is:
>
> Thu Feb 28 08:48:50 2019 VERIFY ERROR: depth=0, error=format error in
> certificate's notAfter field
> : C=de, L=Dortmund, O=Versatel, CN=ASG_1, emailAddress=...
>
> The certificate has those fields:
>
>         Validity
>
>             Not Before: Oct 22 13:28:29 2009 GMT
>
>             Not After : Mar  8 13:28:29 2037 GMT
>
> The customer provided us with a „…..ca.crt“ file, a „….user.crt“ file
> and a „user.key“ file. But I fear it is not smart to post those files in the internet ;-).
>
> Best regards
>
> Wolfgang
>
>
--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
Reply | Threaded
Open this post in threaded view
|

AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Wolfgang Knauf
In reply to this post by Jan Just Keijser-2

Hi,

 

this is the output of „-dates“:

 

C:\Program Files\OpenVPN\bin>openssl.exe x509 -dates -subject -noout -in ..\config\[hidden email]\l1139218.vt-security.de.ca.crt

notBefore=Oct 22 13:28:29 2009 GMT

notAfter=Mar  8 13:28:29 2037 GMT

subject=C = de, L = Dortmund, O = Versatel, CN = Versatel VPN CA, emailAddress = [hidden email]

 

Would it be OK if I send the crt file to only your mail adress? I don't feel save by posting it to the mailing list ;-)?

 

Best regards

 

Wolfgang

 

Von: Jan Just Keijser <[hidden email]>
Gesendet: Montag, 4. März 2019 10:07
An: Wolfgang Knauf <[hidden email]>; [hidden email]
Betreff: Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

 

Hi,

On 04/03/19 09:08, Wolfgang Knauf wrote:

Hi,

 

I first asked this question in the OpenVPNGui forum, and they redirected me to here: OpenVPNGui 2.4.6 works with a customers server certificate, but it fails when using 2.4.7.

 

Here is the thread in the OpenVPNGui forum: https://forums.openvpn.net/viewtopic.php?f=24&t=27976

 

The error is:

Thu Feb 28 08:48:50 2019 VERIFY ERROR: depth=0, error=format error in certificate's notAfter field: C=de, L=Dortmund, O=Versatel, CN=ASG_1, emailAddress=...

 

The certificate has those fields:

        Validity

            Not Before: Oct 22 13:28:29 2009 GMT

            Not After : Mar  8 13:28:29 2037 GMT

 

The customer provided us with a „…..ca.crt“ file, a „….user.crt“ file and a „user.key“ file. But I fear it is not smart to post those files in the internet ;-).

 

 

you can safely post the client.crt file - it is public info and useless without the key file. 

Having said that, I just created a certificate set to expire on Mar 9 2037 and it passed the following command:
  c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in mycert.crt

can you run the same command on the failing certificate?

HTH,

JJK / Jan Just Keijser

Reply | Threaded
Open this post in threaded view
|

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Richard Levitte - VMS Whacker-2
In reply to this post by Jan Just Keijser-2
On Mon, 04 Mar 2019 10:06:54 +0100,
Jan Just Keijser wrote:
...
> Having said that, I just created a certificate set to expire on Mar 9 2037 and it passed the
> following command:
>   c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in mycert.crt
>
> can you run the same command on the failing certificate?

That's a poor test.  'openssl x509' doesn't verify the certificate,
and the error comes up during verification.  To verify, use 'openssl
verify'.  Here's an example with OpenSSL test files:

    openssl verify -trusted test/certs/root-cert.pem test/certs/ca-cert.pem

So in Wolfgang's case, I suspect something like this would say more:

    openssl verify -trusted .....ca.crt .....user.crt

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
Reply | Threaded
Open this post in threaded view
|

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Jan Just Keijser-2
Hi Richard,

On 04/03/19 10:27, Richard Levitte wrote:

> On Mon, 04 Mar 2019 10:06:54 +0100,
> Jan Just Keijser wrote:
> ...
>> Having said that, I just created a certificate set to expire on Mar 9 2037 and it passed the
>> following command:
>>    c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in mycert.crt
>>
>> can you run the same command on the failing certificate?
> That's a poor test.  'openssl x509' doesn't verify the certificate,
> and the error comes up during verification.  To verify, use 'openssl
> verify'.  Here's an example with OpenSSL test files:
>
>      openssl verify -trusted test/certs/root-cert.pem test/certs/ca-cert.pem
>
> So in Wolfgang's case, I suspect something like this would say more:
>
>      openssl verify -trusted .....ca.crt .....user.crt
>

you were one step ahead of me :)
I fully agree that it is a poor test, I was just wondering if there was
an encoding error in the cert itself, esp as the EndDate approaches the
32bit epoch...

Wolfgang, can you send me both the client cert and the CA cert that goes
with it? both are public info.

cheers,

JJK / Jan Just Keijser

Reply | Threaded
Open this post in threaded view
|

AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Wolfgang Knauf
Here is the output:

C:\Program Files\OpenVPN\bin>openssl.exe verify -trusted ..\config\[hidden email]\l1139218.vt-security.de.ca.crt ..\config\[hidden email]\l1139218.vt-security.de.user.crt
..\config\[hidden email]\l1139218.vt-security.de.user.crt: OK

But it seems I don't have the root certificate, just the CA certificate?

I will send both certificate files in another mail.

Wolfgang

-----Ursprüngliche Nachricht-----
Von: openssl-users <[hidden email]> Im Auftrag von Jan Just Keijser
Gesendet: Montag, 4. März 2019 10:36
An: Richard Levitte <[hidden email]>; [hidden email]
Betreff: Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Hi Richard,

On 04/03/19 10:27, Richard Levitte wrote:

> On Mon, 04 Mar 2019 10:06:54 +0100,
> Jan Just Keijser wrote:
> ...
>> Having said that, I just created a certificate set to expire on Mar 9
>> 2037 and it passed the following command:
>>    c:\program files\openvpn\bin\openssl x509 -dates -subject -noout
>> -in mycert.crt
>>
>> can you run the same command on the failing certificate?
> That's a poor test.  'openssl x509' doesn't verify the certificate,
> and the error comes up during verification.  To verify, use 'openssl
> verify'.  Here's an example with OpenSSL test files:
>
>      openssl verify -trusted test/certs/root-cert.pem
> test/certs/ca-cert.pem
>
> So in Wolfgang's case, I suspect something like this would say more:
>
>      openssl verify -trusted .....ca.crt .....user.crt
>

you were one step ahead of me :)
I fully agree that it is a poor test, I was just wondering if there was an encoding error in the cert itself, esp as the EndDate approaches the 32bit epoch...

Wolfgang, can you send me both the client cert and the CA cert that goes with it? both are public info.

cheers,

JJK / Jan Just Keijser

Reply | Threaded
Open this post in threaded view
|

Re: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Jan Just Keijser-2
In reply to this post by Wolfgang Knauf
On 04/03/19 10:21, Wolfgang Knauf wrote:

> Hi,
>
> the output is this:
>
> C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in ..\config\[hidden email]\l1139218.vt-security.de.user.crt
> Error: offset too large
>
> Would it be OK if I send the crt file to only your mail adress? I don't feel save by posting it to the mailing list ;-)?
>
>
I ran into the "offset too large" problem myself with my own certs as
well. It turns out the 'asn1parse' util only likes PEM blobs, i.e. the
parts starting with --BEGIN CERTIFICATE--

You can use
   openssl x509 -in l1139218.vt-security.de.user.crt -out | openssl
ans1parse
to work around this.
For your certificates this results in

     0:d=0  hl=4 l= 942 cons: SEQUENCE
     4:d=1  hl=4 l= 791 cons: SEQUENCE
     8:d=2  hl=2 l=   3 cons: cont [ 0 ]
    10:d=3  hl=2 l=   1 prim: INTEGER           :02
    13:d=2  hl=2 l=   9 prim: INTEGER           :C604316CD0321FA1
    24:d=2  hl=2 l=  13 cons: SEQUENCE
    26:d=3  hl=2 l=   9 prim: OBJECT :sha256WithRSAEncryption
    37:d=3  hl=2 l=   0 prim: NULL
[...]
   155:d=2  hl=2 l=  30 cons: SEQUENCE
   157:d=3  hl=2 l=  13 prim: UTCTIME           :160418140054Z
   172:d=3  hl=2 l=  13 prim: UTCTIME           :370308132808Z
   187:d=2  hl=2 l=  88 cons: SEQUENCE
   189:d=3  hl=2 l=  11 cons: SET
   191:d=4  hl=2 l=   9 cons: SEQUENCE
   193:d=5  hl=2 l=   3 prim: OBJECT            :countryName
   198:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :de

In other words, the dates look OK to me.
Also, I've thrown my own verification code against the certificate and
everything checks out OK.
I'll see if I can reproduce the issue in my own OpenVPN setup.

HTH,

JJK / Jan Just Keijser

Reply | Threaded
Open this post in threaded view
|

Re: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Matt Caswell-2


On 04/03/2019 13:16, Jan Just Keijser wrote:

> On 04/03/19 10:21, Wolfgang Knauf wrote:
>> Hi,
>>
>> the output is this:
>>
>> C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in
>> ..\config\[hidden email]\l1139218.vt-security.de.user.crt
>> Error: offset too large
>>
>> Would it be OK if I send the crt file to only your mail adress? I don't feel
>> save by posting it to the mailing list ;-)?
>>
>>
> I ran into the "offset too large" problem myself with my own certs as well. It
> turns out the 'asn1parse' util only likes PEM blobs, i.e. the parts starting
> with --BEGIN CERTIFICATE--

asn1parse will expect PEM by default but is perfectly capable of processing raw
DER too. Just use the "-inform DER" option.

Matt

Reply | Threaded
Open this post in threaded view
|

AW: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Wolfgang Knauf
In reply to this post by Jan Just Keijser-2
Might the reason for this error be some server certificate that I don't have locally but that is downloaded/checked during the OpenVPNGui connection?

Sorry is this is a dumb questions, but I am just a user of OpenVPNGui and don't have knowledge about the internals...

Wolfgang

-----Ursprüngliche Nachricht-----
Von: Jan Just Keijser <[hidden email]>
Gesendet: Montag, 4. März 2019 14:16
An: Wolfgang Knauf <[hidden email]>; [hidden email]
Betreff: Re: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

On 04/03/19 10:21, Wolfgang Knauf wrote:

> Hi,
>
> the output is this:
>
> C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in
> ..\config\[hidden email]\l1139218.vt-security.de.use
> r.crt
> Error: offset too large
>
> Would it be OK if I send the crt file to only your mail adress? I don't feel save by posting it to the mailing list ;-)?
>
>
I ran into the "offset too large" problem myself with my own certs as well. It turns out the 'asn1parse' util only likes PEM blobs, i.e. the parts starting with --BEGIN CERTIFICATE--

You can use
   openssl x509 -in l1139218.vt-security.de.user.crt -out | openssl ans1parse to work around this.
For your certificates this results in

     0:d=0  hl=4 l= 942 cons: SEQUENCE
     4:d=1  hl=4 l= 791 cons: SEQUENCE
     8:d=2  hl=2 l=   3 cons: cont [ 0 ]
    10:d=3  hl=2 l=   1 prim: INTEGER           :02
    13:d=2  hl=2 l=   9 prim: INTEGER           :C604316CD0321FA1
    24:d=2  hl=2 l=  13 cons: SEQUENCE
    26:d=3  hl=2 l=   9 prim: OBJECT :sha256WithRSAEncryption
    37:d=3  hl=2 l=   0 prim: NULL
[...]
   155:d=2  hl=2 l=  30 cons: SEQUENCE
   157:d=3  hl=2 l=  13 prim: UTCTIME           :160418140054Z
   172:d=3  hl=2 l=  13 prim: UTCTIME           :370308132808Z
   187:d=2  hl=2 l=  88 cons: SEQUENCE
   189:d=3  hl=2 l=  11 cons: SET
   191:d=4  hl=2 l=   9 cons: SEQUENCE
   193:d=5  hl=2 l=   3 prim: OBJECT            :countryName
   198:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :de

In other words, the dates look OK to me.
Also, I've thrown my own verification code against the certificate and everything checks out OK.
I'll see if I can reproduce the issue in my own OpenVPN setup.

HTH,

JJK / Jan Just Keijser

Reply | Threaded
Open this post in threaded view
|

Re: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Jan Just Keijser-2
In reply to this post by Matt Caswell-2
Hi Matt,

On 04/03/19 14:24, Matt Caswell wrote:

>
> On 04/03/2019 13:16, Jan Just Keijser wrote:
>> On 04/03/19 10:21, Wolfgang Knauf wrote:
>>> Hi,
>>>
>>> the output is this:
>>>
>>> C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in
>>> ..\config\[hidden email]\l1139218.vt-security.de.user.crt
>>> Error: offset too large
>>>
>>> Would it be OK if I send the crt file to only your mail adress? I don't feel
>>> save by posting it to the mailing list ;-)?
>>>
>>>
>> I ran into the "offset too large" problem myself with my own certs as well. It
>> turns out the 'asn1parse' util only likes PEM blobs, i.e. the parts starting
>> with --BEGIN CERTIFICATE--
> asn1parse will expect PEM by default but is perfectly capable of processing raw
> DER too. Just use the "-inform DER" option.
>
>
100% true but that is not what I was referring to; my certs usually look
like this:

Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number: 5338 (0x14da)
         Signature Algorithm: sha256WithRSAEncryption
[...]
-----BEGIN CERTIFICATE-----
MIIEmjCCA4KgAwIBAgICFNowDQYJKoZIhvcNAQELBQAwUjELMAkGA1UEBhMCTkwx


it's that part *before* the --BEGIN CERTIFICATE--  on which the
asn1parse command chokes. You can feed it either a DER file or a PEM
blob - but not a certificate file with the certificate info listed in it.

JJK

Reply | Threaded
Open this post in threaded view
|

Re: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Hubert Kario
On Monday, 4 March 2019 15:20:36 CET Jan Just Keijser wrote:

> Hi Matt,
>
> On 04/03/19 14:24, Matt Caswell wrote:
> > On 04/03/2019 13:16, Jan Just Keijser wrote:
> >> On 04/03/19 10:21, Wolfgang Knauf wrote:
> >>> Hi,
> >>>
> >>> the output is this:
> >>>
> >>> C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in
> >>> ..\config\[hidden email]\l1139218.vt-security.de.user.
> >>> crt
> >>> Error: offset too large
> >>>
> >>> Would it be OK if I send the crt file to only your mail adress? I don't
> >>> feel save by posting it to the mailing list ;-)?
> >>
> >> I ran into the "offset too large" problem myself with my own certs as
> >> well. It turns out the 'asn1parse' util only likes PEM blobs, i.e. the
> >> parts starting with --BEGIN CERTIFICATE--
> >
> > asn1parse will expect PEM by default but is perfectly capable of
> > processing raw DER too. Just use the "-inform DER" option.
>
> 100% true but that is not what I was referring to; my certs usually look
> like this:
>
> Certificate:
>      Data:
>          Version: 3 (0x2)
>          Serial Number: 5338 (0x14da)
>          Signature Algorithm: sha256WithRSAEncryption
> [...]
> -----BEGIN CERTIFICATE-----
> MIIEmjCCA4KgAwIBAgICFNowDQYJKoZIhvcNAQELBQAwUjELMAkGA1UEBhMCTkwx
>
>
> it's that part *before* the --BEGIN CERTIFICATE--  on which the
> asn1parse command chokes. You can feed it either a DER file or a PEM
> blob - but not a certificate file with the certificate info listed in it.
ah, yes, that's https://github.com/openssl/openssl/issues/7317

that should be possible to workaround with -strictpem option

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Jan Just Keijser-2
In reply to this post by Richard Levitte - VMS Whacker-2
Hi all,

On 04/03/19 10:01, Richard Levitte wrote:

> The format error refers to how the numbers are encoded in the
> certificate.  The best way to see for ourselves is if you can run
> 'openssl asn1parse' on the certificate and show us the sequence that
> contains the notBefore and notAfter time-stamps.  The are seen
> together between the issuer name and the subject name.
>
> As an example, here's the 'openssl asn1parse' output for
> test/testx509.pem:
>
>      : ; openssl asn1parse -i -in test/testx509.pem
>          0:d=0  hl=4 l= 347 cons: SEQUENCE
>          4:d=1  hl=4 l= 262 cons:  SEQUENCE
>          8:d=2  hl=2 l=   1 prim:   INTEGER           :18
>         11:d=2  hl=2 l=  13 cons:   SEQUENCE
>         13:d=3  hl=2 l=   9 prim:    OBJECT            :md5WithRSAEncryption
>         24:d=3  hl=2 l=   0 prim:    NULL
>         26:d=2  hl=2 l=  56 cons:   SEQUENCE
>         28:d=3  hl=2 l=  11 cons:    SET
>         30:d=4  hl=2 l=   9 cons:     SEQUENCE
>         32:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
>         37:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :AU
>         41:d=3  hl=2 l=  12 cons:    SET
>         43:d=4  hl=2 l=  10 cons:     SEQUENCE
>         45:d=5  hl=2 l=   3 prim:      OBJECT            :stateOrProvinceName
>         50:d=5  hl=2 l=   3 prim:      PRINTABLESTRING   :QLD
>         55:d=3  hl=2 l=  27 cons:    SET
>         57:d=4  hl=2 l=  25 cons:     SEQUENCE
>         59:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
>         64:d=5  hl=2 l=  18 prim:      PRINTABLESTRING   :SSLeay/rsa test CA
>         84:d=2  hl=2 l=  30 cons:   SEQUENCE
>         86:d=3  hl=2 l=  13 prim:    UTCTIME           :950619233312Z
>        101:d=3  hl=2 l=  13 prim:    UTCTIME           :950717233312Z
>        116:d=2  hl=2 l=  58 cons:   SEQUENCE
>        118:d=3  hl=2 l=  11 cons:    SET
>        120:d=4  hl=2 l=   9 cons:     SEQUENCE
>        122:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
>        127:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :AU
>        131:d=3  hl=2 l=  12 cons:    SET
>        133:d=4  hl=2 l=  10 cons:     SEQUENCE
>        135:d=5  hl=2 l=   3 prim:      OBJECT            :stateOrProvinceName
>        140:d=5  hl=2 l=   3 prim:      PRINTABLESTRING   :QLD
>        145:d=3  hl=2 l=  29 cons:    SET
>        147:d=4  hl=2 l=  27 cons:     SEQUENCE
>        149:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
>        154:d=5  hl=2 l=  20 prim:      PRINTABLESTRING   :SSLeay/rsa test cert
>        176:d=2  hl=2 l=  92 cons:   SEQUENCE
>        178:d=3  hl=2 l=  13 cons:    SEQUENCE
>        180:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
>        191:d=4  hl=2 l=   0 prim:     NULL
>        193:d=3  hl=2 l=  75 prim:    BIT STRING
>        270:d=1  hl=2 l=  12 cons:  SEQUENCE
>        272:d=2  hl=2 l=   8 prim:   OBJECT            :md5
>        282:d=2  hl=2 l=   0 prim:   NULL
>        284:d=1  hl=2 l=  65 prim:  BIT STRING
>
> Here, the notBefore and notAfter are the following lines:
>
>         84:d=2  hl=2 l=  30 cons:   SEQUENCE
>         86:d=3  hl=2 l=  13 prim:    UTCTIME           :950619233312Z
>        101:d=3  hl=2 l=  13 prim:    UTCTIME           :950717233312Z
>
> For visualization, this is the text form output of the same:
>
>      : ; openssl x509 -in test/testx509.pem -dates -noout
>      notBefore=Jun 19 23:33:12 1995 GMT
>      notAfter=Jul 17 23:33:12 1995 GMT
>
> So now, for the encoding, RFC5280 has a few things to say
> (https://tools.ietf.org/html/rfc5280#section-4.1.2.5).  However, for
> the dates you display, it should be easy, the should be the following:
>
>      UTCTIME :091022132829Z
>      UTCTIME :370308132829Z
>
> If you see something violently different (such as GeneralizedTime
> instead of UTCTIME), or the number of digits being wrong (12 for
> UTCTIME, 14 for GeneralizedTime), or there being something other than
> 'Z' at the end, then you know why you get that error.
>
> (I encoded those numbers manually, so I hope I got them right)
>
> Cheers,
> Richard
>
> On Mon, 04 Mar 2019 09:08:30 +0100,
> Wolfgang Knauf wrote:
>>
>> Hi,
>>
>> I first asked this question in the OpenVPNGui forum, and they redirected me to here: OpenVPNGui
>> 2.4.6 works with a customers server certificate, but it fails when using 2.4.7.
>>
>> Here is the thread in the OpenVPNGui forum: https://forums.openvpn.net/viewtopic.php?f=24&t=27976
>>
>> The error is:
>>
>> Thu Feb 28 08:48:50 2019 VERIFY ERROR: depth=0, error=format error in certificate's notAfter field
>> : C=de, L=Dortmund, O=Versatel, CN=ASG_1, emailAddress=...
>>
>> The certificate has those fields:
>>
>>          Validity
>>
>>              Not Before: Oct 22 13:28:29 2009 GMT
>>
>>              Not After : Mar  8 13:28:29 2037 GMT
>>
>> The customer provided us with a „…..ca.crt“ file, a „….user.crt“ file and a „user.key“ file. But I
>> fear it is not smart to post those files in the internet ;-).
>>
>>
as a follow-up:  Richard's analysis/suspicion was spot on.
However, it was the *server* side certificate that was causing the
error, and the server certificate does indeed contain a poorly formatted
date:

$ openssl asn1parse -in server.crt | grep UTC
   157:d=3  hl=2 l=  13 prim: UTCTIME           :091022132829Z
   172:d=3  hl=2 l=  17 prim: UTCTIME           :370308132808+0000

OpenSSL 1.0.x groks this, 1.1+ does not.

cheers,

JJK / Jan Just Keijser
Reply | Threaded
Open this post in threaded view
|

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Richard Levitte - VMS Whacker-2
On Wed, 06 Mar 2019 10:52:44 +0100,
Jan Just Keijser wrote:
> as a follow-up:  Richard's analysis/suspicion was spot on.
> However, it was the *server* side certificate that was causing the
> error, and the server certificate does indeed contain a poorly
> formatted date:
>
> $ openssl asn1parse -in server.crt | grep UTC
>   157:d=3  hl=2 l=  13 prim: UTCTIME           :091022132829Z
>   172:d=3  hl=2 l=  17 prim: UTCTIME           :370308132808+0000

I'm glad I could help find the answer.

> OpenSSL 1.0.x groks this, 1.1+ does not.

Yup, 1.1+ is stricter regarding these things.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
Reply | Threaded
Open this post in threaded view
|

AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Wolfgang Knauf
Many thanks to all of you for your help! Sorry for posting those basic questions, but I was helpless - I am just a VPN client user, with not much knowledge of SSL :-(.

I forwarded the problem to our customer. Hopefully, they have more knowledge than me about certificates ;-).

Best regards

Wolfgang

-----Ursprüngliche Nachricht-----
Von: openssl-users <[hidden email]> Im Auftrag von Richard Levitte
Gesendet: Mittwoch, 6. März 2019 11:07
An: [hidden email]
Betreff: Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

On Wed, 06 Mar 2019 10:52:44 +0100,
Jan Just Keijser wrote:
> as a follow-up:  Richard's analysis/suspicion was spot on.
> However, it was the *server* side certificate that was causing the
> error, and the server certificate does indeed contain a poorly
> formatted date:
>
> $ openssl asn1parse -in server.crt | grep UTC
>   157:d=3  hl=2 l=  13 prim: UTCTIME           :091022132829Z
>   172:d=3  hl=2 l=  17 prim: UTCTIME           :370308132808+0000

I'm glad I could help find the answer.

> OpenSSL 1.0.x groks this, 1.1+ does not.

Yup, 1.1+ is stricter regarding these things.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
Reply | Threaded
Open this post in threaded view
|

RE: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Michael Wojcik
In reply to this post by Richard Levitte - VMS Whacker-2
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Richard Levitte
> Sent: Wednesday, March 06, 2019 03:07
>
> On Wed, 06 Mar 2019 10:52:44 +0100,
> Jan Just Keijser wrote:
> > as a follow-up:  Richard's analysis/suspicion was spot on.
> > However, it was the *server* side certificate that was causing the
> > error, and the server certificate does indeed contain a poorly
> > formatted date:
> >
> > $ openssl asn1parse -in server.crt | grep UTC
> >   157:d=3  hl=2 l=  13 prim: UTCTIME           :091022132829Z
> >   172:d=3  hl=2 l=  17 prim: UTCTIME           :370308132808+0000
>
> I'm glad I could help find the answer.
>
> > OpenSSL 1.0.x groks this, 1.1+ does not.
>
> Yup, 1.1+ is stricter regarding these things.

I would have expected 1.0.2p and later to have rejected this as well, since the RFC 5280 restrictions on validity date attributes were included in that release. There was some discussion about it on the OpenSSL lists, with some people suggesting that a change to insist on the letter of the standard which broke compatibility with certificates generated by some other implementations was not a great idea. (I am sympathetic to this argument myself, and feel there should at least be an option to relax these restrictions.)

See for example: https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html

It's interesting to note that back in 2009 when GeneralizedTime support for X.509 dates was added to OpenSSL, Erwann Abalea pointed out that RFC 5280 is only a profile of X.509, and X.509 itself allows timezone offsets and fracttional seconds, and so arguably OpenSSL ought to allow them too (presumably for use by non-TLS X.509 applications). (See e.g. http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.) Personally, I find that argument persuasive too, and think that it would be appropriate to have a mechanism to disable the 5280 checks.

Maybe I'll put together a PR, though I don't know if it has much chance of being accepted.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



Reply | Threaded
Open this post in threaded view
|

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Blumenthal, Uri - 0553 - MITLL
Since OpenSSL is more than just a TLS implementation, I agree with Michael and support relaxing these checks when appropriate.

Regards,
Uri

Sent from my iPhone

On Mar 6, 2019, at 10:22, Michael Wojcik <[hidden email]> wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf Of
>> Richard Levitte
>> Sent: Wednesday, March 06, 2019 03:07
>>
>> On Wed, 06 Mar 2019 10:52:44 +0100,
>> Jan Just Keijser wrote:
>>> as a follow-up:  Richard's analysis/suspicion was spot on.
>>> However, it was the *server* side certificate that was causing the
>>> error, and the server certificate does indeed contain a poorly
>>> formatted date:
>>>
>>> $ openssl asn1parse -in server.crt | grep UTC
>>>   157:d=3  hl=2 l=  13 prim: UTCTIME           :091022132829Z
>>>   172:d=3  hl=2 l=  17 prim: UTCTIME           :370308132808+0000
>>
>> I'm glad I could help find the answer.
>>
>>> OpenSSL 1.0.x groks this, 1.1+ does not.
>>
>> Yup, 1.1+ is stricter regarding these things.
>
> I would have expected 1.0.2p and later to have rejected this as well, since the RFC 5280 restrictions on validity date attributes were included in that release. There was some discussion about it on the OpenSSL lists, with some people suggesting that a change to insist on the letter of the standard which broke compatibility with certificates generated by some other implementations was not a great idea. (I am sympathetic to this argument myself, and feel there should at least be an option to relax these restrictions.)
>
> See for example: https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html
>
> It's interesting to note that back in 2009 when GeneralizedTime support for X.509 dates was added to OpenSSL, Erwann Abalea pointed out that RFC 5280 is only a profile of X.509, and X.509 itself allows timezone offsets and fracttional seconds, and so arguably OpenSSL ought to allow them too (presumably for use by non-TLS X.509 applications). (See e.g. http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.) Personally, I find that argument persuasive too, and think that it would be appropriate to have a mechanism to disable the 5280 checks.
>
> Maybe I'll put together a PR, though I don't know if it has much chance of being accepted.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

OpenSSL - User mailing list
In reply to this post by Michael Wojcik
On 06/03/2019 16:17, Michael Wojcik wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf Of
>> Richard Levitte
>> Sent: Wednesday, March 06, 2019 03:07
>>
>> On Wed, 06 Mar 2019 10:52:44 +0100,
>> Jan Just Keijser wrote:
>>> as a follow-up:  Richard's analysis/suspicion was spot on.
>>> However, it was the *server* side certificate that was causing the
>>> error, and the server certificate does indeed contain a poorly
>>> formatted date:
>>>
>>> $ openssl asn1parse -in server.crt | grep UTC
>>>    157:d=3  hl=2 l=  13 prim: UTCTIME           :091022132829Z
>>>    172:d=3  hl=2 l=  17 prim: UTCTIME           :370308132808+0000
>> I'm glad I could help find the answer.
>>
>>> OpenSSL 1.0.x groks this, 1.1+ does not.
>> Yup, 1.1+ is stricter regarding these things.
> I would have expected 1.0.2p and later to have rejected this as well, since the RFC 5280 restrictions on validity date attributes were included in that release. There was some discussion about it on the OpenSSL lists, with some people suggesting that a change to insist on the letter of the standard which broke compatibility with certificates generated by some other implementations was not a great idea. (I am sympathetic to this argument myself, and feel there should at least be an option to relax these restrictions.)
>
> See for example: https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html
>
> It's interesting to note that back in 2009 when GeneralizedTime support for X.509 dates was added to OpenSSL, Erwann Abalea pointed out that RFC 5280 is only a profile of X.509, and X.509 itself allows timezone offsets and fracttional seconds, and so arguably OpenSSL ought to allow them too (presumably for use by non-TLS X.509 applications). (See e.g. http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.) Personally, I find that argument persuasive too, and think that it would be appropriate to have a mechanism to disable the 5280 checks.
>
> Maybe I'll put together a PR, though I don't know if it has much chance of being accepted.
>

RFC5280 etc. is not even a requirement for SSL/TLS (it certainly
can't be for SSL versions before it), only for the publicly
trusted certificates used on the global Internet.  So arguably,
it should not apply to running TLS between closely related
parties (as is the traditional use case for something
like OpenVPN).

Running a private protocol over TLS between my server in one
building and my server in another building doesn't involve
the WebPKI.

It is of cause prudent for libraries to produce RFC5280
compliant certificates by default, and for test tools
(such as the "openssl x509" and "openssl validate"
commands) to warn when a certificate is outside the
standards for public certificates.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Reply | Threaded
Open this post in threaded view
|

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Jan Just Keijser-2
Hi all,

On 06/03/19 16:36, Jakob Bohm via openssl-users wrote:

> On 06/03/2019 16:17, Michael Wojcik wrote:
>>> From: openssl-users [mailto:[hidden email]] On
>>> Behalf Of
>>> Richard Levitte
>>> Sent: Wednesday, March 06, 2019 03:07
>>>
>>> On Wed, 06 Mar 2019 10:52:44 +0100,
>>> Jan Just Keijser wrote:
>>>> as a follow-up:  Richard's analysis/suspicion was spot on.
>>>> However, it was the *server* side certificate that was causing the
>>>> error, and the server certificate does indeed contain a poorly
>>>> formatted date:
>>>>
>>>> $ openssl asn1parse -in server.crt | grep UTC
>>>>    157:d=3  hl=2 l=  13 prim: UTCTIME :091022132829Z
>>>>    172:d=3  hl=2 l=  17 prim: UTCTIME :370308132808+0000
>>> I'm glad I could help find the answer.
>>>
>>>> OpenSSL 1.0.x groks this, 1.1+ does not.
>>> Yup, 1.1+ is stricter regarding these things.
>> I would have expected 1.0.2p and later to have rejected this as well,
>> since the RFC 5280 restrictions on validity date attributes were
>> included in that release. There was some discussion about it on the
>> OpenSSL lists, with some people suggesting that a change to insist on
>> the letter of the standard which broke compatibility with
>> certificates generated by some other implementations was not a great
>> idea. (I am sympathetic to this argument myself, and feel there
>> should at least be an option to relax these restrictions.)
>>
>> See for example:
>> https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html
>>
>> It's interesting to note that back in 2009 when GeneralizedTime
>> support for X.509 dates was added to OpenSSL, Erwann Abalea pointed
>> out that RFC 5280 is only a profile of X.509, and X.509 itself allows
>> timezone offsets and fracttional seconds, and so arguably OpenSSL
>> ought to allow them too (presumably for use by non-TLS X.509
>> applications). (See e.g.
>> http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.)
>> Personally, I find that argument persuasive too, and think that it
>> would be appropriate to have a mechanism to disable the 5280 checks.
>>
>> Maybe I'll put together a PR, though I don't know if it has much
>> chance of being accepted.
>>
>
> RFC5280 etc. is not even a requirement for SSL/TLS (it certainly
> can't be for SSL versions before it), only for the publicly
> trusted certificates used on the global Internet.  So arguably,
> it should not apply to running TLS between closely related
> parties (as is the traditional use case for something
> like OpenVPN).
>
> Running a private protocol over TLS between my server in one
> building and my server in another building doesn't involve
> the WebPKI.
>
> It is of cause prudent for libraries to produce RFC5280
> compliant certificates by default, and for test tools
> (such as the "openssl x509" and "openssl validate"
> commands) to warn when a certificate is outside the
> standards for public certificates.
>
so to recapitulate:
- OpenSSL 1.1+ (and possible 1.0.2<X>) introduced stricter RFC5280
checks when doing certificate validation
- This causes certificates that contain fields that are not fully
RFC5280 compliant to fail validation
- However, as Jakob states, there is no requirement in TLS for RFC5280
compliance

Should this be considered a bug in OpenSSL then? If this is not
considered a bug, shouldn't OpenSSL then state this as a requirement for
certificate creaton?

Of course, the easy solution is to tell people to create and use RFC5280
compliant certificates, but what if someone has a legitimate use case
for not being able or wanting to do so?
Is there a way to loosen the verification checks (apart from writing a
custom verify_callback) ?

thanks for any advice,

JJK / Jan Just Keijser
12