bug Odd (OpenSSL?) bug and types in X509 certs

[Angus Robertson 574]

Not sure from this thread what you are doing with these certificates, but if they are on a public web server you can try a test at https://www.ssllabs.com/ssltest/ which is good at testing certificate chains for errors.

 

Angus

 

[m227 2]

My only activity is to parse them and extract signer first and last name, and country. ICS does it well.

Michal

[Angus Robertson 574]

Is it okay to put your SSL certificates in the OpenSSL mailing list, to try and find out why some can not be read? 

 

I've improved the reading of certificate files and bundles to get some meaningful errors, rather than stack error.  For instance if I remove some lines of base64, I get  'Error Cert 4 - error:0D07209B:asn1 encoding routines:ASN1_get_object:too long' and more ASN1 errors, but reading your bad certificates just says 'Error Cert 1 - error:00000000:lib(0):func(0):reason(0)' which essentially means no error found. 

 

Angus

 

[m227 2]

What can I say? Does it mean that if no error found so OpenSSL 1.1.1 is spoiled? They are read using 1.1.0 with no problem and 1.1.1 does not read them. I don't know what library you use to have your Error Cert 1 and if it is error or not.

[Angus Robertson 574]

My point was the OpenSSL error is so serious it is not even reported, which is why I want to escalate it to OpenSSL support, let them examine your certificates and hopefully fix it?

 

Angus

 

[m227 2]

Do these certificates contain any sensitive private data? If not I/we/you can send them to proper OpenSSL programmers.

Edited June 25, 2020 by m227

[Guest]

My two cents on this,

 

You are not sure if the private key is there, this leads to to question the source of those certificates, you didn't share them so i will guess here, i think OpenSSL might be protecting the users from special hand crafted certificates, like the ones concerns CVE-2020-0601, where the curve parameters had been crafted to to match fake CA while maintaining the identification parameters of the original/real CA.

 

This might be the case, and in this case you should first compare the Issuer of those certificates with already known certificates, and make sure the curve parameters are not included only the NIST name, OID is in RFC's and it is not a custom algorithm (implicitCurve,  specifiedCurve  )means no custom curve parameters included, this trick is happening with CA pretending to emulate the public key of the real CA, so the public key will be the same with all fields (like issuer, Subject Key Identifier, dates, serial.. etc) the hardest thing to emulate is hash of the certificate but this also can be faked to match the real CA ( very hard but doable, Google "chosen-prefix collision attack on SHA1", or read this https://www.schneier.com/blog/archives/2020/01/new_sha-1_attac.html) 

So to filter such certificates, your should refer to https://tools.ietf.org/html/rfc5480#section-2.1.1 for those certificates to be used with SSL/TLS they should only be namedCurve and the value should be one from those in section 2.1.1.1

 

And this might be not case, as those certificate has a defect and OpenSSL decided to stop parsing them.

 

Anyway without seeing them it is hard to tell but why not try different software to see its reaction and to read their info, like XCA https://hohnstaedt.de/xca/ 

[m227 2]

Those certificates I extracted form XAdES file form X509 nodes. And they are successfully read (the credentials) by some web services as well as using ICS and OpenSSL 1.1.0. As a matter of fact I don't want to check validity of certificates or if they are forged, but extract names of signers. OpenSSL 1.1.0 does the job while 1.1.1 does not. I sent the files to Angus but if you are able and kind to check their contents I can send them on priv. I am myself not too fluent in security topics.

[Guest]

If they extracted then nothing private with them, means no private key and no harm can be done by disclosing them, no need for the XAdES file.

If you prefer not to paste them here, then please send me one, but if XAdES was having a chain then i need the full chain ( usually two or three when chain is included) , not only the end certificate (the signer).

[Angus Robertson 574]

The certificates do not have private keys, but do have private names, they are client certificates.  No purpose in posting them here, but I will escalate to OpenSSL.  

 

Angus

 

[m227 2]

Angus, thank you for help. Maybe Kas Ob. is right, that if I chopped them out from XAdES I ommited some other necessary data in chain?

Kas Ob. I sent you files on priv. If you still require XAdES I'll find it and send.

 

Michal

[Angus Robertson 574]

No, don't need any more from you, OpenSSL should be able to read these certificates or say what is wrong with them, so it's their bug, not ours.

 

Angus

 

[Guest]

Thank you, 

I just checked them and they are just fine.

 

First i tried to open them with XCA , the bad ones caused XCA to hang.

Then i tried to load them using SecureBlackBox, and i could read them without any problem at all, tried to export them again, now they works with XCA. @m227 will send you the fixed one.

 

Yes, as Agnus said, it is OpenSSL bug.

@m227 I sent you the fixed ones, you may try to validate them as without the full chain i can't do it.

 

EDIT: removing many spaces

Edited June 25, 2020 by Guest

[Guest]

Forgot to mention they have RSA Keys so the CVE-2020-0601 mentioned above doesn't apply to them.

 

And the RSA public key does have the usual and popular exponent 65537, in short nothing exotic about those (bad) certificates.

[Angus Robertson 574]

Another OpenSSL user has briefly tested the certificates and believes they contain badly formed UTF8, probably ANSI which is how this topic started.  The issue will be whether OpenSSL should open badly formatted certificates in future, even if it did in the past. 

 

Angus

 

[Guest]

Agnus, they are valid and correct in that account, i mean UTF8 and ANSI, the problem is in how OpenSSL 1.1.1 is parsing PEM format itself.

 

from https://tools.ietf.org/html/rfc7468#section-2 

Quote

Generators MUST wrap the base64-encoded lines so that each line
   consists of exactly 64 characters except for the final line, which
   will encode the remainder of the data (within the 64-character line
   boundary), and they MUST NOT emit extraneous whitespace.  Parsers MAY
   handle other line sizes.  These requirements are consistent with PEM
   [RFC1421].

Both bad and OK certificates are not wrapped at 64 char length, so why it does accept and parse some and refused the others ?

Secondly after i opened them with SSB library and save them, they start to work fine with OpenSSL, i just compared the content of the bad and the OK, and the only difference is the CR+LF ( $13#10) every 64 char, that is it, not a byte difference.

Thirdly if those PEM file is not generated by OpenSSL, then this also a bug or not standard way to export PEM.

 

I will send you in private the screenshot of that comparison and the working certs to compare by your self, if you wish and if the OP is ok with that, he already has the correct formatted PEM files, he even can compare them.

 

[Angus Robertson 574]

The original certificates are unwrapped base64 and that is how I tested them. however I manually line wrapped them for the OpenSSL mailing list since email does like 2,500 long lines. 

 

When I rest them line wrapped, my latest ICS says 'Reading X509 Base64 certificate: Error Cert 1 - error:09091064:PEM routines:PEM_read_bio_ex:bad base64 decode' for the bad certificate and the asn1parase command works for the OK certificate and gives a real error for the bad one.

 

I'll fix ICS to reject unwrapped certificates since OpenSSL can not reliably handle them. 

 

Angus

[Guest]

But, you already discovered a bug in OpenSSL and i think you should report it.

It should either refuse all unwrapped PEM's or accept them all. i don't see any problem in parsing one line PEM data or wrongly wrapped PEM, specially searching the internet is really confusing about this subject, like this

https://docs.vmware.com/en/Unified-Access-Gateway/3.5/com.vmware.uag-35-deploy-config.doc/GUID-870AF51F-AB37-4D6C-B9F5-4BFEB18F11E9.html

 

And that is not breaking any Base64 data integrity.

[Angus Robertson 574]

I made a mistake word wrapping one of the bad certificates and lost a character, when corrected it reads correctly with ICS and OpenSSL.

 

It is frustrating OpenSSL does not handle unwrapped certificates consistently and I've raised that as an issue.

 

But Michal can fix his original problem by ensuring the files are created according to the RFC with 64 character long lines, they are from some source other than ICS.   In theory I could word wrap them, but I think I'll just add a better error if OpenSSL fails. 

 

Angus

 

 

[m227 2]

Thank you for further investigation. Does it mean that if I programmatically wrap them every 64 ASCII characters, OpenSSL 1.1.1 will accept them all?

[Angus Robertson 574]

Yes, I've only tried two of your four certificates, but they can be read by OpenSSL with short lines.  If none had worked with long lines, this would have been a lot easier to diagnose.

 

Angus

 

[m227 2]

Well done, I chopped my base64 with a nifty code:

  procedure ChopToLines(var AString: String; const AEveryChars: Integer = 64; ASeparator: String = #13#10);
  var
    i: Integer;
  begin
    i := AEveryChars;
    while Length(AString) > i do
    begin
      Insert(ASeparator, AString, i + 1);
      inc(i, AEveryChars + Length(ASeparator));
    end;
  end;

and it Works with OpenSSL 1.1.1 !!!

Thank you for help

 

[Guest]

One thing though, instead of expecting AString to be valid Base64, try to sanitize it from anything not Base64 character, then after that chop it, such it will work even if there is CRLF not in right place.

https://base64.guru/learn/base64-characters

Quote

• Uppercase letters (indices 0-25): ABCDEFGHIJKLMNOPQRSTUVWXYZ
• Lowercase letters (indices 26-51): abcdefghijklmnopqrstuvwxyz
• Digits (indices 52-61): 0123456789
• Special symbols (indices 62-63): +/

 

[m227 2]

Kas Ob., I get my base64 from XAdES files from: Signature\KeyInfo\X509Data\X509Certificate

so it should be always a valid single line base64 string. The only difference is that in XAdES has it without linebreaks.

[Angus Robertson 574]

Never heard of XAdES, but if it's a toolkit they should not be generating unwrapped base64 lines, I'd raise that as a bug with them on the basis that OpenSSL does not correctly support it...

 

Angus