Jump to content
merijnb

Odd (OpenSSL?) bug and types in X509 certs

Recommended Posts

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

Michal

Share this post


Link to post

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

 

Share this post


Link to post

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.

Share this post


Link to post

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

 

Share this post


Link to post

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

Edited by m227

Share this post


Link to post
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/ 

Share this post


Link to post

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.

Share this post


Link to post
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).

Share this post


Link to post

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

 

Share this post


Link to post

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

Share this post


Link to post

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

 

Share this post


Link to post
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 by Guest

Share this post


Link to post
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.

Share this post


Link to post

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

 

Share this post


Link to post
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.

 

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post

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

 

 

Share this post


Link to post

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?

Share this post


Link to post

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

 

Share this post


Link to post

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:classic_biggrin::classic_cheerleader:

 

Share this post


Link to post
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): +/

 

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×