ASN1 error on generated CSR

[imi415]

The CSR file generated has an invalid INTEGER (l=0) which generates errors on openssl. Error information:

Error reading certificate request in test.csr
140173603737536:error:0D0E20DE:asn1 encoding routines:c2i_ibuf:illegal zero content:crypto/asn1/a_int.c:154:
140173603737536:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:609:Field=version, Type=X509_REQ_INFO
140173603737536:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:609:Field=req_info, Type=X509_REQ
140173603737536:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:crypto/pem/pem_oth.c:33:

Difference between CSRs generated by openssl and csrgenerator.com

openssl:
    0:d=0  hl=4 l=1297 cons: SEQUENCE          
    4:d=1  hl=4 l= 761 cons: SEQUENCE          
    8:d=2  hl=2 l=   1 prim: INTEGER           :00
   11:d=2  hl=2 l= 119 cons: SEQUENCE          
   13:d=3  hl=2 l=  11 cons: SET               
   15:d=4  hl=2 l=   9 cons: SEQUENCE          
   17:d=5  hl=2 l=   3 prim: OBJECT            :countryName

csrgenerator.com:
    0:d=0  hl=4 l= 699 cons: SEQUENCE          
    4:d=1  hl=4 l= 419 cons: SEQUENCE          
    8:d=2  hl=2 l=   0 prim: INTEGER           :BAD INTEGER:[]
   10:d=2  hl=2 l= 119 cons: SEQUENCE          
   12:d=3  hl=2 l=  11 cons: SET               
   14:d=4  hl=2 l=   9 cons: SEQUENCE          
   16:d=5  hl=2 l=   3 prim: OBJECT            :countryName

[imi415]

It happens in openssl 1.1.0g, while openssl 1.0.2n doesn't consider this as an error. However, in the case of openssl 1.0.2n, it failed to decode strings and treated them as different strings.

Check that the request matches the signature
Signature ok
The organizationName field needed to be the same in the
CA certificate (iM.Inc) and the request (iM.Inc)

[DavidWittman]

Thanks @imi415... I'm not quite sure what the impact of this issue is, aside from the errors when parsing in OpenSSL. Do you know what this integer represents?

[imi415]

Sorry that I'm not very familiar with crypto and PKI. But after doing some search, I found something may be useful here, in RFC2986 page 5 and 6:

4.1 CertificationRequestInfo

   Certification request information shall have ASN.1 type
   CertificationRequestInfo:

   CertificationRequestInfo ::= SEQUENCE {
        version       INTEGER { v1(0) } (v1,...),
        subject       Name,
        subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
        attributes    [0] Attributes{{ CRIAttributes }}
   }

...

The components of type CertificationRequestInfo have the following
   meanings:

        version is the version number, for compatibility with future
          revisions of this document.  It shall be 0 for this version of
          the standard.

It seems like this is the version of the file itself, and shall be zeroed currently. Comparing the CSRs above shows that the latter one ignored this field and gave an attribute which has size 0.

[imi415]

As for me, I don't know how public PKIs do with this kind of thing either, but they may have different crypto suites besides OpenSSL.

[HarukaMa]

Could not reproduce this on python 2.7.12 + openssl 1.0.2g. Maybe the backend needs an update to openssl library?

[DavidWittman]

I just updated to 1.0.2k on https://csrgenerator.com, so this may be resolved there. I had to patch for Spectre/Meltdown anyway so I just bit the bullet and upgraded everything.

[tidoublemy]

I've run into this issue in a different context and came across this thread and thought I'd share some info. The behavior comes from OpenSSL itself and is specific to the 1.1.x releases. You won't see it in any of the releases in the 1.0.2 series, so that's why DavidWittman and HarukaMa were unable to reproduce it. imi415, on the other hand, was using 1.1.0g when encountering it. I believe it originates in this refactoring: https://github.com/openssl/openssl/commit/6c5b6cb035666d46495ccbe4a4f3d5e3a659cd40#diff-d53e2b0a865eb8230c9f2512c067ceca

The issue isn't the presence of the 0 in the CSR but in the way the 0 is encoded. My understanding is that it's not valid to encode it with a length of 0 (it should be encoded with the octets 02 01 00 rather than just 02 00), but that must be what CSRGenerator is doing. OpenSSL versions before 1.1.0 tolerated this incorrect encoding, but newer versions do not.

[DavidWittman]

@tidoublemy Does that mean that upgrading csrgenerator.com to openssl 1.1.x would presumably fix this issue?

Edit: thanks for the helpful feedback btw!

[tidoublemy]

Do you know what version of openssl you were running when the problem was originally encountered? I think you're actually already ok but that info may help in my investigation.

On Wed, Feb 20, 2019, 6:08 PM David Wittman <notifications@github.com wrote:

@tidoublemy https://github.com/tidoublemy Does that mean that upgrading csrgenerator.com to openssl 1.1.x would presumably fix this issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DavidWittman/csrgenerator.com/issues/22#issuecomment-465792391, or mute the thread https://github.com/notifications/unsubscribe-auth/AE4GfdsN23_0PNm9XutRQY0dkl48iAQ0ks5vPdVSgaJpZM4ROXaF .