Question

I have a certificate that has the following chain of certification: Entrust->My CA->My Issuing CA->My JBoss Certificate. Now, if I install my certificate on my JBoss instance, any page I access running on this instance will appear untrusted as My Issuing CA is not recognized by my browser. I know that my computer has the public key for the Entrust signing authority. How can I install my certificate so that any browser can see the entire certificate chain?

I made a single .pem file of all of the certificates thinking that would work. It did not. Can anyone explain what I am doing wrong or even if this is possible?

Was it helpful?

Solution

Adding an intermediate certificates to a pkcs12 file ...

Here's how I do it on my web and mail servers.

First, www-example-com.crt is the web server cert signed by Startcom. Startcom offers free Class 1 certificates trusted my most browsers and mobile devices, so I use them. The certificate is in PEM format (----- BEGIN CERT ----- and ----- END CERT -----).

Second, I open www-example-com.crt and append Startcom's Class 1 Intermediate. I get the intermediate from Startcom's Index of /certs. Now my www-example-com.crt has two PEM encoded encoded certs in it.

Third, I perform the following to create a PKCS12/PFX file for use in IIS.

openssl pkcs12 -export -in www-example-com.crt -inkey www.example.key -out www-example-com.p12

In your case, your www-example-com.crt will have at least three PEM encoded certificates in it:

----- BEGIN CERT -----
< My JBoss Certificate >
----- END CERT -----

----- BEGIN CERT -----
< My Issuing CA >
----- END CERT -----

----- BEGIN CERT -----
< My CA >
----- END CERT -----

The third cert in the chain - My CA - is optional. You don't need it if your clients use My CA as a trust anchor. If you're clients use Entrust as a trust anchor, then you will need to include it.

If you cat your www-example-com.crt and it does NOT have multiple certificates, then do not continue. Don't perform openssl pkcs12 until your server cert has all the required intermediate certificates required to verify the chain.

Do not include the Entrust CA certificate.


I doubt Entrust signs with their CA directly. They probably use an intermediate, too. So your cert chain should probably look like:

----- BEGIN CERT -----
< My JBoss Certificate >
----- END CERT -----

----- BEGIN CERT -----
< My Issuing CA >
----- END CERT -----

----- BEGIN CERT -----
< My CA >
----- END CERT -----

----- BEGIN CERT -----
< Entrust Intermediate >
----- END CERT -----

Entrusts provides their CA and Intermediate certificates at Entrust Root Certificates. I can't tell you which one you need because you won't provide a URL or show us the chain you have. But I'm guessing its going to be one or more of:

  • Entrust L1E Chain Certificate
  • Entrust L1C Chain Certificate
  • Entrust L1E Chain Certificate (SHA2)
  • Entrust L1C Chain Certificate (SHA2)

You can test your chain with OpenSSL's `s_client. This time, you will use Entrust's certifcate:

echo -e "GET / HTTP/1.0\r\n" | openssl s_client -connect myserver:8443 \
                                       -CAfile entrust-ca.pem

You can get entrust-ca.pem from Entrust Root Certificates. Run it and tell us what errors you get. Or better, post the URL to your server so we can see what's going on.

OTHER TIPS

I have a certificate that has the following chain of certification: Entrust->My CA->My Issuing CA->My JBoss Certificate....

I think you have two problems here. First is the countersigned CA, and second is an incomplete client chain.

First, the easy problem. The server must send the end entity (server) cert and any intermediate certs to required build the chain. The server sends the intermediate certs to avoid the "which directory" problem. The "which directory" is a well know problem in PKI. Essentially, the client does not know where to go to fetch the missing intermediate cert.

So your first solution is for the server to send a chain with:

  • Your intermediate cert ('My Issuing CA')
  • Your server cert ('My JBoss Certificate')

Second, you have the problem of an untrusted issuer. The client must trust your internal issuing CA.

So your second solution is to ensure your client trusts your internal CA ('My CA'). In this case, there's no need for the client to even use Entrust since the trust point is rooted in your internal CA.

You may be able to have the server send a chain with 'My CA', ''My Issuing CA' and 'My JBoss Certificate'. In this case the client must trust 'Entrust'.

If the client does not trust either 'Entrust' or 'My CA', then you will get verification errors.


I made a single .pem file of all of the certificates thinking that would work. It did not. Can anyone explain what I am doing wrong or even if this is possible?

In this case, we would need to see the certificates in an effort to see what's going on. Can you post a URL that serves the certificate and uses the chain; and post you internal CA ('My CA') cert online?

Here's a quick and dirty way to test a connection with OpenSSL's s_client:

echo -e "GET / HTTP/1.0\r\n" | openssl s_client -connect myserver:8443 \
                                       -CAfile my-issuing-ca.pem

OpenSSL trusts nothing by default (unlike browsers), so you have to specify your trust anchor with -CAfile.

That command should end with something similar to the following.

SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 37E5AF0EE1745AB2...
    Session-ID-ctx:
    Master-Key: 7B9F8A79D3CC3A41...
    Key-Arg   : None
    Start Time: 1243051912
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

If the OpenSSL command results in OK, then the problem is with the browser and the trust point.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top