SSL Root CA and Intermediate CA Certs.

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

SSL Root CA and Intermediate CA Certs.

Kaushal Shriyan-2
Hi,

I am new to SSL/TLS Certificates. Please help me understand what is the difference between ROOT CA Certs and Intermediate Certs or Chain Certs. I will appreciate if i can refer to some books or tutorials to know about SSL/TLS technology.

Thanks and Regards,

Kaushal
Reply | Threaded
Open this post in threaded view
|

Re: SSL Root CA and Intermediate CA Certs.

Graham Leggett
On 23 Apr 2014, at 2:23 PM, Kaushal Shriyan <[hidden email]> wrote:

> I am new to SSL/TLS Certificates. Please help me understand what is the difference between ROOT CA Certs and Intermediate Certs or Chain Certs. I will appreciate if i can refer to some books or tutorials to know about SSL/TLS technology.

The closest thing you'll probably encounter in the real world to a digital certificate is a diploma or degree from an educational institution.

Anyone can write "John Smith (PhD)" on a piece of paper, that doesn't indicate anything special or prove anything. We might improve that by writing "John Smith (PhD), Faculty of Philosophy" on that piece of paper, but again, which faculty of philosophy? Never heard of them. Still, the piece of paper is useless. We can however write "John Smith (PhD), Faculty of Philosophy, University of Cambridge" on the piece of paper and sign the paper by putting a great big seal on the paper to make the paper hard to forge. In theory, we have heard of and trust the University of Cambridge, and in turn the University of Cambridge trusts the Faculty of Philosophy, which in turn trusts John Smith. If we trust the University of Cambridge, then we trust John Smith.

If we were using digital certificates instead of a certificate you might hang on a wall we might create a certificate called "cn=John Smith (PhD)" and get John Smith to sign it. This cert is largely meaningless, given that in order to trust John Smith we need to already trust John Smith using some out-of-band method. This is a self signed certificate.

If we were using certificates with a full certificate authority, we would instead have a certificate called "cn=John Smith (PhD)" issued by and signed by "ou=Faculty of Philosophy" which is in turn issued by and signed by "o=University of Cambridge". The "o=University of Cambridge" certificate is called the ROOT CA certificate, because we have manually trusted that one using an out of band method (we might have got it built into our browser). The intermediate certificate is the "ou=Faculty of Philosophy" certificate, which is trusted by "o=University of Cambridge" and trusts "cn=John Smith (PhD). John Smith is the leaf certificate trusted by the others.

All you need to do is trust the root CA certificate "o=University of Cambridge", and you automatically trust everyone they trust, including "cn=John Smith (PhD)". Instead of relying on a big elaborate piece of paper with a wax seal on it, you rely on a mathematical equation that verifies that the certificate is legitimate, but the idea is the same.

Regards,
Graham
--

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SSL Root CA and Intermediate CA Certs.

Alan Buxey
Hi,

> > I am new to SSL/TLS Certificates. Please help me understand what is the difference between ROOT CA Certs and Intermediate Certs or Chain Certs. I will appreciate if i can refer to some books or tutorials to know about SSL/TLS technology.
>
> The closest thing you'll probably encounter in the real world to a digital certificate is a diploma or degree from an educational institution.

and to take this anaology to the final step.... University of Cambridge is the Root - you know and trust..... other Universities and Technical colleges are roots too - you know and trust
them (your certificate store/keychain will be full of trusted Roots) - however, other
orgs can hand out degrees too...these are affiliated to the main (root) CAs and have a lot
of rules/checks/balances.... so,

john smith, Degree from College of Town, underwritten by University of Foo

you trust Foo....so you then trust College of Town.... which means you trust the
degree John holds.  College of Town is, in this case, an intermediate Certificate.

alan
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SSL Root CA and Intermediate CA Certs.

Edward Ned Harvey (openssl)
In reply to this post by Kaushal Shriyan-2
> From: [hidden email] [mailto:owner-openssl-
> [hidden email]] On Behalf Of Kaushal Shriyan
>
> I am new to SSL/TLS Certificates. Please help me understand what is the
> difference between ROOT CA Certs and Intermediate Certs or Chain Certs. I
> will appreciate if i can refer to some books or tutorials to know about SSL/TLS
> technology.

I don't know how you learn about SSL/TLS, other than (a) reading the internet, and working on it a lot, (b) taking some courses on general cryptography (there is a free online course at coursera.com, which is quite good.)  and (c) the thing that I actually found the most useful, a general book on cryptography called Cryptography Engineering, by Bruce Schneier, Niels Ferguson,  Tadayashi Kohno.

The root cert is self signed (so it is signed by itself.)  The intermediate cert is signed by the root cert.  And your leaf cert is signed by the intermediate.

A client who receives the cert chain (the root, intermediate, and leaf) can follow a process to (1) verify that the leaf cert is not corrupted, and that the intermediate cert has verified it.  (b) verify that the intermediate cert is not corrupted, and that the root cert has verified it, and that the intermediate cert is in fact authorized by the root cert to perform the authorization of the leaf cert.  and (c) verify that the root cert is among the list of certs that the client "trusts."

How and why do you trust any root certs?  Generally they're built-in to your OS or your browser, so you're just blindly trusting that those guys know what they're doing.
:��I"Ϯ��r�m���� (���Z+�K�+����1���x ��h���[�z�(���Z+� ��f�y������f���h��)z{,���
Reply | Threaded
Open this post in threaded view
|

RE: SSL Root CA and Intermediate CA Certs.

Michael Wojcik
> From: [hidden email] [mailto:owner-openssl-
> [hidden email]] On Behalf Of Edward Ned Harvey (openssl)
> Sent: Wednesday, 23 April, 2014 21:05
> Subject: RE: SSL Root CA and Intermediate CA Certs.
>
> I don't know how you learn about SSL/TLS, other than (a) reading the
> internet,

Man, I *tried* to read the Internet, but to be honest I got bogged down somewhere around 2.0.0.0.

> (b) taking some courses on general
> cryptography (there is a free online course at coursera.com, which is quite
> good.)  and (c) the thing that I actually found the most useful, a general
> book on cryptography called Cryptography Engineering

I'd argue that knowing about cryptography, and especially about implementing cryptography, is not very helpful for understanding SSL/TLS. Once you understand the purpose of the primitives - symmetric and asymmetric encryption, message digests, and digital signatures - the details don't help you with the SSL/TLS protocols themselves, or even with choosing cipher suites. (While some suites are vulnerable to particular attacks, you can take the word of crypto experts on those points and weigh them against your threat model. Understanding the specifics of the threat isn't necessary.) And understanding the details of cryptographic implementation won't help at all with PKI.

So I'd suggest starting with a quick cryptography primer that covers the primitives, and then something like Rescorla's /SSL and TLS/ book. It's not an exciting read, but then SSL/TLS is not an exciting subject.

For someone who does want more background in cryptography, I'd recommend Schneier's /Applied Cryptography/ over /Cryptography Engineering/. The latter is for people implementing cryptography, which beginners should never do. As a rule of thumb, don't attempt to implement cryptography until you know when it's appropriate to violate this rule. And as Schneier himself has pointed out numerous times, cryptography isn't the problem, or the solution, anyway. ("If you think cryptography is the solution to your problem, you don't understand cryptography and you don't understand your problem.")
 
> How and why do you trust any root certs?  Generally they're built-in to your
> OS or your browser, so you're just blindly trusting that those guys know what
> they're doing.

And they don't, and they don't care that they don't. The SSL/TLS X.509-with-well-known-CAs PKI is fundamentally broken and frequently compromised. But there's little we can do about it, so we pretend it isn't.

Of course the point of *any* security system is to raise the work factor for attackers until the cost of breaking the system is greater than the return for breaking it, under your threat model. SSL/TLS raises that cost over unencrypted communications. But it doesn't raise it nearly as much as it ought to, thanks to broken protocols, broken implementations, broken PKI, mismanagement, and user error.

--
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com
:��I"Ϯ��r�m���� (���Z+�K�+����1���x ��h���[�z�(���Z+� ��f�y������f���h��)z{,���
Reply | Threaded
Open this post in threaded view
|

RE: SSL Root CA and Intermediate CA Certs.

Edward Ned Harvey (openssl)
> From: [hidden email] [mailto:owner-openssl-
> [hidden email]] On Behalf Of Michael Wojcik
>
> For someone who does want more background in cryptography, I'd
> recommend Schneier's /Applied Cryptography/ over /Cryptography
> Engineering/. The latter is for people implementing cryptography, which
> beginners should never do.

Huh - I thought Cryptography Engineering was the 3rd edition of Applied Cryptography, renamed.  But now I look at it, it seems you're right, it's a different book entirely.  However, I never got the impression that Cryptography Engineering was meant for people implementing new algorithms or anything like that.  They very roundly and repeatedly beat into you, don't do that, without loads and loads of courses in mathematics, and a thoroughly vetted public and expert review process.  (Such as AES/SHA, etc).  They do a nice round job of covering the basics, describing what a block cipher is, what a hash algorithm is, PKI, symmetric/asymmetric, etc, what the characteristics are, how to think about threat models, and how to use these things in the ways that they're intended to be used, etc.  So don't discount Cryptography Engineering, but definitely consider Applied Cryptography in addition, or instead.
:��I"Ϯ��r�m���� (���Z+�K�+����1���x ��h���[�z�(���Z+� ��f�y������f���h��)z{,���
Reply | Threaded
Open this post in threaded view
|

Re: SSL Root CA and Intermediate CA Certs.

Bruce Stephens-4
"Edward Ned Harvey (openssl)"
<openssl-Z8efaSeK1ezqlBn2x/[hidden email]> writes:

>> From: [hidden email] [mailto:owner-openssl-
>> [hidden email]] On Behalf Of Michael Wojcik
>>
>> For someone who does want more background in cryptography, I'd
>> recommend Schneier's /Applied Cryptography/ over /Cryptography
>> Engineering/. The latter is for people implementing cryptography, which
>> beginners should never do.
>
> Huh - I thought Cryptography Engineering was the 3rd edition of
> Applied Cryptography, renamed.  But now I look at it, it seems you're
> right, it's a different book entirely.

Second edition of Practical Cryptography:
<https://www.schneier.com/book-practical.html>

> However, I never got the impression that Cryptography Engineering was
> meant for people implementing new algorithms or anything like that.

True, "implementing" isn't quite the right word. "Using" would be
closer, I suspect, though that doesn't necessarily carry the notion of
engineering (it's not a book about how to use PGP, or use some product
that incorporates TLS).

[...]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SSL Root CA and Intermediate CA Certs.

Mark H. Wood
In reply to this post by Michael Wojcik
On Thu, Apr 24, 2014 at 12:57:36PM +0000, Michael Wojcik wrote:
[snip]
> > How and why do you trust any root certs?  Generally they're built-in to your
> > OS or your browser, so you're just blindly trusting that those guys know what
> > they're doing.
>
> And they don't, and they don't care that they don't. The SSL/TLS X.509-with-well-known-CAs PKI is fundamentally broken and frequently compromised. But there's little we can do about it, so we pretend it isn't.

Well, there certainly is something we can do about it, but you won't
like it any more than I do:

1.  Empty all of your trust stores.
2.  Add the cert.s of all CAs you already trust (if any) to your
    trust stores.
3.  Investigate each CA you don't yet trust.  As you come to trust
    one, add it to your trust stores.
4.  Pay attention to the CAs you trust, and evict any that seem to
    have declined to a degree that worries you.
5.  Goto 3.

--
Mark H. Wood, Lead System Programmer   [hidden email]
Machines should not be friendly.  Machines should be obedient.

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Blocking or Logging Heartbeat in application code

Tim Hudson
In reply to this post by Edward Ned Harvey (openssl)
I've put up an example of how the OpenSSL msg_callback capability can be
used in an application to detect (and to block the connection by forcing
a close of the connection) independent of the OpenSSL library code.

The preferred approach is always to upgrade to a patched release - but
if you are unsure if your release is patched or you don't have
sufficient access to install patched libraries on your system this
option is a way to handle it.

https://gist.github.com/t-j-h/11337380

The code fragment is shows an example msg_callback and there is a block
at the end showing how to plug it into your application.

Tim.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]