2

Ok. So, here is what I know:

  1. SSL Certificate are used to verify domain for HTTPS protocol. These are issued by a root CA to ensure that it can be trusted by anyone using the website and trusting the CA as well.

  2. A self signed SSL certificate won't be trusted because I am not a root CA and the user doesn't know me.

  3. DSC (Digital Signature Certificate) is issued by a root CA to me and it has a private/public key pair and I can use this to sign things. Since it is issued by root CA too, I can sign documents and those can be verified by the third party.

Here's my question:

Is there a way to generate a SSL certificate using my DSC (Class 2) and use it for a secure SSL/HTTPS website? because in theory, this will create a whole chain of trust reaching the root CA.

(I have used both SSL & DSC and I just want to have a conceptual clarity here. I may definitely be missing something here.)

|improve this question

migrated from stackoverflow.com Oct 26 '15 at 2:35

This question came from our site for professional and enthusiast programmers.

3

Certificates have depths, which increase as you go down a trust chain, so certificate depth 0 issues certificate depth 1, which issues certificate depth 2, etc...

To satisfactorily verify a full certificate chain, a client connecting to your SSL secured website would have to be able to find the intermediaries, and verify them, until it reaches a trusted certificate, which under any normal circumstances is a CA certificate installed with your OS.

An arbitrary client would not find your intermediary certificate in this case, because it will be equipped with all the usual certificates installed with the OS, but of course, it won't have your intermediary...

A desktop computer, or server, built as part of some sort of special corporate build for the company, can of course be tampered with, by adding certificates, and some companies do this, adding their own root CA with all the other default ones.

Your SSL secured web server can however provide intermediate certificates (along with its own) to the client when it connects so that it can complete the chained trust verification process, but...

The next problem is the intermediate certificate, the one issued to you by your CA, may not be valid as a CA itself, and if so it won't be accepted as an intermediate certificate.

Using openssl you can check this by running 'openssl x509':

openssl x509 -text -in CERT_FILENAME

Trying this on a CA certificate, looking through the output, you can see:

                ef:47:91:0a:72:ba:9e:85:3c:7e:39:6b:62:ed:d0:
                13:53:cf:52:52:e2:a8:1a:a8:27:5c:7e:08:a2:ad:
                17:1d
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Subject Key Identifier: 
            5C:FC:C1:89:C0:DC:DD:C7:01:0D:EA:37:73:A8:7B:F4:55:85:A5:E4
        X509v3 Authority Key Identifier: 
            keyid:5C:FC:C1:89:C0:DC:DD:C7:01:0D:EA:37:73:A8:7B:F4:55:85:A5:E4

        X509v3 Basic Constraints: 
            CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
     17:e4:1d:18:d6:43:68:75:04:11:c0:6f:72:6b:ac:eb:03:18:
     1c:f3:e3:94:f8:77:b5:40:38:3b:20:cd:42:d7:de:db:7c:98:

The magic bit that you are looking for is:

            CA:TRUE

If CA is FALSE or the x509 extensions aren't there, it's not going to work as an intermediate CA.

Finally, also if you have openssl, you can do "openssl s_client -connect som.ssl.web.site:443 -CApath /path/to/your/CAcerts -verify 5", and hopefully you should, near the end of a load of output, get:

Verify return code: 0 (ok)

Where your intermediate is not valid as a CA though, you will get:

Verify return code: 26 (unsupported certificate purpose)

I tested this generating a CA, then an intermediate certificate, and an 'end' certificate signed by the intermediate, and although the chain of trust is verifiable successfully, used on a website, it does not work. If I generate a V3 intermediate with x509 extensions, setting the basic constraints of CA to TRUE, and then generate an 'end' certificate signed by that, again the trust chain is fine, but this time the web client is happy.

|improve this answer
  • Ok. Yes, that someone connecting to my website needs to reach the root CA. But my DSC is issued from a root CA too and hence it's publicly verifiable. Many SSLs issued are not for root CA directly but by their trusted CAs. So yes, the depth will be more but is it possible? – Som Shekhar Oct 23 '15 at 18:58
  • I just had a bit of a look into it, and actually although everything I said is correct, the crucial thing that is unsaid, is that certificates can have constraints, so whilst there's nothing to stop you creating more certificates trusted by the certificate the CA issued you with, it is probably not be valid as a CA itself. If you use openssl you can check with "openssl x509 -text -in CERT_FILENAME". Look for "X509v3 Basic Constraints:" and under that "CA:TRUE". If it says "CA:FALSE" or it isn't there or you can't find basic constraints then it won't be accepted as an intermediate CA. – Michael Oct 23 '15 at 21:00
  • I'm going to add this to my answer above so it's clear. – Michael Oct 23 '15 at 21:01
  • Though I am not completely clear yet but I get what you are saying. The best might be to try this and test over some temporary site. – Som Shekhar Oct 24 '15 at 12:34
  • Yep, try the openssl commands I listed though if you can, and, also if you have openssl you can do "openssl s_client -connect som.ssl.web.site:443 -CApath /path/to/your/CAcerts -verify 5"... hang on... I will add this to the end of the answer as well, it's too long for a comment... – Michael Oct 24 '15 at 12:45

Your Answer

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