4

I am completely new to OpenSSL and I'm reading a tutorial on OpenSSL programming to connect to a server:

www.rtfm.com/openssl-examples/part1.pdf
www.rtfm.com/openssl-examples/part2.pdf

Somehow setting up the correct certificates is more tricky than expected... :(

When I test the message with openssl s_client:

openssl s_client -connect 123.456.789.0:666 -CAfile test.crt -debug

I get the error message

depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority verify error:num=20:unable to get local issuer certificate verify return:0

and then:

error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate:s3_pkt.c:1257:SSL alert number 42 140685406562208:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:

Here is the certificate chain:

 Certificate chain  
 0 
   s:myself    
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA  
 1 
   s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA    
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority  
 2 
   s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority    
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

I am trying to get the system to recognize these certificates as correct for hours now but to no avail...

What i have tried until now:

  • various variations of adding the certificate of COMODO to the list of trusted certificates by using update-ca-trust.
  • adding the certificates to the list of trusted certificates in /etc/ssl/certs
  • creating pem files in a folder and adding them with -CApath.
  • The problem with google is that most tutorials discuss this from the point of view of a server admin, but I don't have access to the server.

The operating system is Fedora.

Is there a structured way to tackle this issue?


Edit: the certificate was created as follows:

 openssl req -new -x509 -sha256 -days 365 -key mykey.key -out test.crt
3
  • 2
    Is the test.crt file really a CA Bundle? That doesn't look right... What exactly are you trying to do?
    – Chris S
    Jul 28, 2014 at 16:57
  • @ChrisS I had to provide a self-signed certificate to the host. The host people have integrated my certificate into their system. Now I would like to connect to the host using my certificate. Therefore the CA Bundle contains only my file.
    – Beginner
    Jul 28, 2014 at 17:05
  • That's not what the CAFile option is for. It's a list of Certificate Authorities' root certificates that your client trusts, so when the server provides a certificate the client has something to verify that against. You want to specify your certificate private key (not bundled with any other certificates) with the -key option if you're doing certificate based client authentication. Also, the command you listed below is not a self-signed certificate, it's just the public key that corresponds with the private key (mykey.key).
    – Chris S
    Jul 28, 2014 at 20:22

2 Answers 2

6

Be sure to include all the intermediate certificates and see that they are up to date. If test.crt is in fact a file containing only /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root, this is the correct approach. You can include the root as well, and most clients will accept such chains, but a few will choke.

In general it's best practice to include all the certificates from yours to the last one before the root, in case a client doesn't have the last intermediate.

It's also possible that test.crt contains things other than the correct chain. OpenSSL doesn't do partial chain validation by default (in older versions, it doesn't do it at all). When operating in this mode it doesn't care what is in /etc/ssl/certs.

Alternatively, you may be presenting an expired intermediary certificate. CAs often recertify their intermediates with the same key; if they do that, just download the updated intermediate CA certificate and replace the expired one in your chain.

Finally, with openssl s_client, you need to specify what it is validating against. For example, use the option -CApath /etc/ssl/certs or -CAfile your_ca.crt. For the first option use your system's trust store, and for the second option specify the root CA certificate.

3
  • Ok, feel stupid now. Question: my own certificate was created by >openssl req -new -x509 -sha256 -days 365 -key mykey.key -out test.crt what is the CA for the resulting certificate?
    – Beginner
    Jul 28, 2014 at 17:08
  • 1
    Oh, interesting. The certificate chain you are seeing doesn't correspond with that at all; perhaps they had it signed or something, or are using a different one? You would be testing correctly, were they presenting the contents of that file. Jul 28, 2014 at 17:13
  • You shouldn't include the root in the chain supplied by the server. Certain old clients (Java, possibly others) will fail to connect if you do.
    – Mark
    Jan 12, 2015 at 9:55
2

Check the cert files against each other.

By default we have 3 files (based on a regular CA or self-signed) :

  • (private) key
  • (public) certificate
  • (public) certificate authority (chain) file <- incl. all intermediaries

So, does the key fit to the cert, and the cert fit to the CA ? Annotation: Though the names are like *.crt or *.key the format is PEM

# (openssl x509 -noout -modulus \
  -in /path/to/server.crt | \
  openssl md5 ; openssl rsa  -noout -modulus \
  -in /path/to/server.key | openssl md5) | uniq

Expected outcome is exactly 1 line, e.g.

(stdin)= a634dfd21796c72dcf8c809d3bacc966

If you see 2 lines then key and cert do NOT match.

If ok, proceed with

# openssl verify -CAfile /path/to/ca.crt /path/to/server.crt

You want to see

server.crt: OK

If one of the two steps fail, you are advised to recreate the certs/keys. If both are ok you know that you have to search at another place to remove your obstacles (permissions, changed CA, does one side work with openssl and the other with GNUTls, ...)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .