0
$\begingroup$

Currently I am working with SSL certificates inside a Ruby on Rails application.

I am storing the certificates in a database along with the corresponding dhparam, and chain. At some point I want to render these fields into real files and publish them to a server.

Although the published certificates work in the client's browser we got in massive trouble with a couple of other apps (including golang services, amazon cloudfront, ...) telling us that the certificate is not correct (e.g. x509: certificate signed by unknown authority).

So I had a look at the certificates that were rendered. The only difference I was able to find is that Ruby's OpenSSL library returns the certificate with a different carriage return than I was used to:

-----BEGIN CERTIFICATE-----\n MIIDhDCCBWygAwIBAgIQDyh/z7hUIji7pFcz+75NWTANBgkqhkiG9w0BAQsFADCB\n kDER ...

but the original, raw string looks like this:

-----BEGIN CERTIFICATE-----\r\n MIIDhDCCBWygAwIBAgIQDyh/z7hUIji7pFcz+75NWTANBgkqhkiG9w0BAQsFADCB\r\n kDER ...

And here's how I rendered the certificate:

certificate = OpenSSL::X509::Certificate.new '<raw certificate>' certificate.to_pem # => This returns the \n formatted certificate

Could the different format of the CRLF be the root of the problem? Are both formats valid?

$\endgroup$
1
$\begingroup$

No, x509: certificate signed by unknown authority shows that the certificate of the Certificate Authority or one of the intermediate certificates issued by it is not present at the other party. It could be that the certificate is very new and it hasn't yet been taken into account, or that the certificate was not received or accepted by the parties you mention. Even more likely is that an intermediate certificate is missing so that the chain to a trusted certificate cannot be made.

To look up the certificates above it the certificates look up the issuer certificate which is referenced by the certificate you send them. Then using that certificate the next certificate is looked up. Finally the signatures within the certificates are verified and the other information (validity period etc.) are validated. This is called chain validation. This ends with a trusted certificate, often the self signed root certificate of the CA.

Obviously to even try to look up the "parent" certificate the certificate must first be parsed. You'd expect another error if the certificate could not be parsed at all.


As for the carriage return: openssl returns only a line-feed character - as most unix utilities probably will. But any implementation that doesn't accept CRLF or even just CR (for Apple) will be in serious trouble, so I don't think you'll find many libraries / applications that won't accept any kind of line ending (and certainly not Amazon etc.).

$\endgroup$
  • $\begingroup$ Okay so there has to be a problem with the ssl chain I provided, right? Thank you for your clarification. $\endgroup$ – zarathustra Feb 23 '17 at 10:09
  • $\begingroup$ Either that or the configuration at the other side, of course. If the chain works in the browser... note that you can check / save all the certificates in the chain from within the browser as well. You could send the chain to them and ask if they're missing a certificate or two. You could also try and add the intermediate certificates to the PEM and send that, maybe they are just missing a few of those. $\endgroup$ – Maarten Bodewes Feb 23 '17 at 10:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.