How Certificates Use Digital Signatures

Update: user rturnbul noticed that I accidentally wrote "private key" when I meant "public key" when discussing man-in-the-middle attacks. My sincerest apologies to anybody who may have been confused by this. I've fixed it; thank you rturnbul.

Anybody who's been using the web for any appreciable amount of time has been presented with ominous, but vague, security warnings such as "this site's certificate has expired", "this site was signed by an untrusted certificate authority", or "the domain name in this site's certificate doesn't match the domain name you've connected to." Research has borne out that most people ignore these warning messages when they're browsing - and honestly, how many of us really know how worried to be? Many web users — even experienced ones — have only a vague notion of what a "certificate" is and what it's for. However, the concept of a certificate — more accurately, an X.509 certificate [1] — is central to modern software security.

As you can probably guess, web browsers secure their traffic using digital cryptography algorithms. Digital cryptography algorithms are "key-based" - meaning that sensitive input is obscured by applying a mathematical algorithm to the input along with a secret key in order to produce meaningless gibberish — gibberish, at least, to everybody except a holder of the secret key. In mathematical terminology, an encryption algorithm E is applied to the sensitive plaintext P along with a secret key K to produce the ciphertext C which can be safely transmitted over an open channel. More succinctly, C = E(P,K). Similarly, a decryption algorithm D is applied by the recipient to retrieve the original plaintext: P = D(C,K).

Broadly speaking, there are two categories of digital cryptography algorithms — symmetric and public. In symmetric algorithms, the same key is used to decrypt the encrypted data as was used to encrypt it in the first place. In public algorithms, the key itself is split into two pieces. One piece is used to encrypt, and the other piece is used to decrypt. The two keys are tightly related — actually generating a public/private keypair is a tricky and precise operation — but once generated, the public key can be freely, and safely, distributed.

The public key is used to do the encrypting, and the private key is used to do the decrypting. This allows two parties to exchange information over a plaintext, unsecured channel without ever meeting or exchanging secrets out of band. The recipient can generate a keypair, send the public key over the insecure channel, and wait for the sender to encrypt something using it. At this point, only the recipient — the holder of the private key — can decrypt the data.

Although there are a few different public-key encryption algorithms, the most popular — and fortunately, the easiest to understand — is the RSA algorithm, named after its three inventors Rivest, Shamir and Adelman. To apply the RSA algorithm, you must find three numbers e, d and n related such that ((me)d) % n = m. Here, e and n comprise the public key and d is the private key. When one party wishes to send a message in confidence to the holder of the private key, he computes and transmits c = (me) % n. The recipient then recovers the original message m using m = (cd) % n.

This almost works. There's a flaw, though, called the "man-in-the- middle" attack. It works like this: an eavesdropper situates himself in between the sender and the recipient. When the would-be recipient transmits his public key, the eavesdropper intercepts it and replaces it with his own public key. The sender, none the wiser, uses this fake public key to encrypt his data. The eavesdropper decrypts it using his own private key, re-encrypts using the recipients public key, and sends it on its way. Neither the sender nor the receiver can detect this, and the whole point of using encryption has been defeated - any sufficiently motivated attacker can listen in on any seemingly secure conversation.

The best known solution to this problem is what's referred to as a "public key infrastructure" (PKI). At the heart of a PKI is a set of trusted authorities who can vouch for the validity of a public key. In this way, if you get a public key from Bob, you just need to check with the trusted authority whether or not this is really Bob's public key. If it's been replaced by a man in the middle, the authority will detect this and warn you.

All well and good, but how do you establish the trust relationship with the authorities in the first place? How do you know that you're talking to an authority and not yet another man-in-the-middle? The answer, again, is centered around public keys — but this time, the purposes are reversed. Just as a public key can be used to encrypt data for the entity that holds the private key, a private key can be used to prove ownership of a public key. Instead of the sender encrypting the data with the public key, the asserting party (the one with the private key) encrypts a bit of data with the private key, and sends both that data (in the clear) and the encrypted data itself. As it turns out, public-key cryptography works in such a way that only the holder of the private key can do this - so if you have access to the public key, you can use it to decrypt the data. If it matches the "token" data, then you can be assured that it was generated by the holder of the private key. Such a token/encrypted data pair is called a digital signature. This works, conceptually at least, like a handwritten signature. Only one person can generate such a handwritten signature (we hope), and that person is assumed to have read over the paper that he's signing. He signs it in ink so that it becomes part of the document, and a future third party can verify the signature to assert that the document was written (or at least authorized) by the signer.

When a keypair is used to sign a message this way, rather than computing c = me%n, the signature is computed as s = md%n (remember that d is the private key, not shared with anybody else). The recipient, who has the public key, can verify the signature by verifying that m = se%n. If so, then s could only have been generated by the holder of the private key. One practical problem with this approach is that s would end up being very long (as long as m), so a cryptographically secure hash such as MD5 or SHA-1[2] which was generated uniquely from m is typically used instead.

This approach allows one party to "vouch" for another. One trusted party can sign the public key of another; the recipient can check the signature and, if he trusts the signer, can be assured that the public key belongs to the bearer. In modern PKI terminology, such a trusted signing party is referred to as a certificate authority. Of course, for this to work, a trust relationship must be established with the certificate authority out of band, but only needs to be done once — once this is done, all subsequent public keys can be checked dynamically.

So, what does all this have to do with certificates? Well, fundamentally, a certificate is a holder for public key, along with a few assertions about the owner of the public key. When you establish a secure connection with a website, that website presents a certificate containing, at least, two pieces of information: the public key of the site and the digital signature supplied by a trusted certificate authority. The browser then uses that public key to establish a secure connection.

Take a look at Amazon's SSL certificate.

Figure 1: Amazon's SSL Certificate

You can see this yourself if you navigate to a secured page on (for instance, your account page), and click the "lock" icon on your browser.

Openssl can output the full details of a certificate in a convenient format:

$ openssl x509 -text -noout -in amazon.cer 
        Version: 3 (0x2)
        Serial Number:
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, 
          OU=Terms of use at (c)09, 
          CN=VeriSign Class 3 Secure Server CA - G2
            Not Before: Jul 15 00:00:00 2010 GMT
            Not After : Jul 14 23:59:59 2013 GMT
        Subject: C=US, ST=Washington, L=Seattle, Inc., 

        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment
            X509v3 CRL Distribution Points: 

            X509v3 Certificate Policies: 
                Policy: 2.16.840.1.113733.

            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Authority Key Identifier: 

            Authority Information Access: 
                OCSP - URI:
                CA Issuers - 

    Signature Algorithm: sha1WithRSAEncryption

Toward the top, underneath "Data", you can see the "Subject" of "C=US, ST=Washington, L=Seattle, Inc.,". This is telling you who the certificate is asserting is identified by the public key. The most important part of the subject name is the "common name" (CN) - here listed as This must match the DNS name of the website that you're connecting to, or your browser will alert you that the certificate is associated with a different domain than the one it was expecting. This makes sense - this is what stops somebody from grabbing Amazon's certificate and masquerading as Amazon on a site named

Below the subject name, you'll see the public key itself. The algorithm is RSA. The exponent e is 65537 and the modulus n is a 128-byte behemoth. What you see here is the hexadecimal representation of a 1,024-bit number. There's no further encoding here; this is the number n used by the RSA algorithm. Notice that it's prefixed by a 0x00 placeholder — this is used to stop some large-number libraries from interpreting this as a negative two's-complement number. If your browser decides to accept this certificate (see below), it will generate yet another key — a one-time-use symmetric cryptography key and securely transmit it to Amazon using the RSA algorithm c=ke%n. Amazon will decrypt it using the private key (which you can't see in the certificate for obvious reasons!) and use that key for subsequent communications.

Just above the subject is the Issuer. This indicates who the signer of this certificate is — in other words, what entity is vouching that this public key does really identify After all, anybody could generate a keypair and a certificate that includes a common name of "". Here, the trusted issuer is identified as "Verisign Class 3 Secure Server CA - G2". The whole thing is signed by "Verisign Class 3 Secure Server CA - G2"'s private key and the signature is shown at the very bottom (and is even longer than the public key modulus!)

So, before accepting this certificate as fact and establishing a secure link with this server, your browser must verify that the signature was generated by "Verisign Class 3 Secure Server CA - G2". First, it computes the secure hash of the whole certificate using the identified signature algorithm "SHA-1". Then it takes the signature and computes se'%n' where e' and n' are the issuer's public key (I'll show you an example in just a minute). It compares this with the hash that it computed — if they match, the certificate is valid (or, at least, it was really signed by Verisign Class 3 Secure Server CA - G2).

What you don't see in this certificate, though, is e' and n' themselves. This makes sense - these numbers have to come from somewhere else, or this certificate would be "self-identifying", which is exactly the problem we're trying to avoid. In fact, the server gave me another certificate - the one containing the signing key.

Figure 2: Verisign Class 3 Secure server CA - G2

Notice that the subject name matches, element for element, the issuer name of the previous certificate. This certificate has its own issuer, public key, and signature, just like the previous certificate as well. And the certificate associated with that signature is displayed:

Figure 3: Verisign Trust Network

Now this is interesting - this certificate lists the same entity in the issuer as in the subject. This certificate is said to be "self-signed" — you can use the public key in the certificate to verify the signature. This is also the same public key that's used to verify the signature of the previous certificate. There are no higher-level certificates — the certificate "chain" ends here.

So far, although the process was complicated, it doesn't seem to have accomplished much — it wouldn't be that hard for an unscrupulous website to generate three fraudulent certificates which vouched for each other, ending in a self-signed top-level certificate. The final piece of the puzzle that holds this whole scheme together is a list of implicitly trusted certificates. Your browser comes with a list of (quite a few) implicitly trusted root certificates — one of these is the certificate in figure 3.

Figure 4: Trusted Roots

In fact, Amazon didn't actually send this certificate — they only sent me the first two, leaving it up to my browser to find the third, top-level certificate to complete the verification process. I can verify this by opening up wireshark and looking at the server certificate message.

Since my browser implicitly trusts this certificate, it permits it to sign the intermediate certificate in figure 2 which it then in turn permits to sign the server certificate in figure 1, and the public key is accepted as belonging to The value in the root certificates lies in your belief that they spent some time verifying that the entity who requested that they sign this certificate really represented the website identified in the common name. I can tell you from experience that this validation varies greatly from one CA to the next. Verisign has refused to issue certificates to me because the articles of incorporation my company filed with the U.S. government didn't match the domain name (!), but GoDaddy just checks to see if they can e-mail the owner of the site as listed by DNS.

It's interesting, and illustrative, to go through the verification process manually (of course, normally, your browser will do it for you automatically so you don't have to). The top-level certificate's public key (the modulus) is the 128-byte value:

According to the RSA signature algorithm, this means that its own (self- signed) signature value of:
if raised to the power of the exponent 65537 and then divided by the modulus, should yield a remainder of the SHA-1 hash of:
(This is, incidentally, not the fingerprint of the certificate displayed in the certificate details window - that fingerprint is generated from the whole certificate, including the signature itself. The signature, obviously, doesn't include itself). This isn't the sort of computation you'd probably want to undertake using pencil and paper (although you're more than welcome to try if you'd like). It's easier to use, for example, Python:
>>> modulus = 0xCC5ED1115D5C69D0ABD3B96A4C991F5998308E168520466D473FD48520
>>> signature = 0x514DCDBE5CCB98199C15B20139782E4D0F67707099C6105A94A4534D
>>> print "%x" % pow( signature, 65537, modulus )
The first bit, the 1fff... part, is the standard RSA algorithm padding and can be removed (if not present, the signature isn't checked any further). What remains is an ASN.1 encoding of the HMAC value. I won't go into the details of ASN.1 parsing here, but the important part is the hash code at the end: D95944F5BD92127092218F9F02C719C42386B499. (The part at the beginning declares both the length and the type — SHA-1 — of the hash code).

Note that this SHA-1 hash is not, itself, stored with the certificate; it's computed by running the contents of the certificate, minus the signature itself, through the SHA-1 algorithm. This way, any change in the certificate body will be detected immediately - the SHA-1 hash won't match the one in the signature.

Now, according to the rules of PKI, the second-level certificate's signature value of:

if "decrypted" using the public key of the top-level certificate, should yield its SHA-1 signature of
Again, this can be verified using Python:
>>> modulus = 0xCC5ED1115D5C69D0ABD3B96A4C991F5998308E168520466D473FD48520
>>> signature = 0x63742F3D53AA2F97EC2611661AFEF1DE412719D27FD8C11CF9E23856
>>> print "%x" % pow( signature, 65537, modulus )

This establishes that the public key in the intermediate certificate can be trusted as belonging to the entity named "VeriSign Class 3 Secure Server CA - G2". Now that this has been established, the browser goes on to check whether the signature in the bottom-level (Amazon's) certificate is valid. Again, this means that the certificate's SHA-1 hash value of:

must be the RSA-encrypted value of the signature:
As encrypted using the issuer's public key modulus. Again, you can use Python to verify that this is the case:
>>> signature = 0xa815fdf5ba5a88990c2a3d28bb7482653f4247211fd478d64d9eb6ec
>>> modulus = 0xd4568f573b3728a64063d295d50574dab5196a96d671572fe2c0348ca0
>>> print "%x" % pow( signature, 65537, modulus )

Now, if I trust the issuer of this certificate, which I do because I trust the issuer of that certificate, which I do because Chrome (my browser) told me it was safe to, I can implicitly trust all of the information contained in the certificate. In particular, I can trust that the server that hosts contains the private key corresponding to the public key contained in the presented certificate. Therefore, it's safe to exchange secrets using it, secure in the knowledge that only this server can decrypt those secrets, and not some man-in-the-middle.

Although the public key is arguably the most important piece of a certificate, the certificate asserts quite a bit more information about the entity named in the subject. One very important piece is the validity period of the certificate itself: each certificate has a "not before" and a "not after" date. Here you can see that Amazon's SSL certificate is valid between July 2010 and July 2013. Regardless of the correctness of the signatures themselves, the certificate will be rejected if the current calendar date falls outside of this period. This is necessary because the private key that this certificate masks is used over and over to authenticate SSL connections. A very determined attacker could use details of these authentications to try to determine the value of the private key. Therefore, it's important to change the private key from time to time. The validity period not only forces the site administrator to do so, but stops an attacker who has compromised the private key from using it — if a private key were compromised, there's no way to "revoke" it, since the public key and private key are related by a simple mathematical relationship. (There's a half-solution to the problem of revoking a compromised private key in "Certificate Revocation Lists" that your browser is supposed to check before it uses a certificate, but CRL's have quite a few problems of their own).

Finally, there is a list of certificate constraints in the section labelled "X509v3 extensions". I won't go through all of these (for more information, see [4]), but one critical extension is "Key Usage". Notice that Amazon's certificate lists key usage of "Digital Signature, Key Encipherment". The issuer's certificate, however, lists key usage of "Certificate Sign, CRL Sign". The distinction is crucial to the concept of PKI. Only a certificate that has a Key Usage extension of "Certificate Sign" can "vouch for" another certificate as detailed above. In particular, Amazon can not use it's SSL certificate to sign another certificate. If they could, they could impersonate anybody! It would be trivial to generate a new certificate with a common name of, say "" and sign it with the public key in the now-trusted Amazon certificate, and your browser would silently accept it.

You may have noticed, however, that this all-important key-usage section falls under a subsection title "X509v3 extensions"... indicating that there were a couple of previous versions of x509 that didn't support this extension. As it turns out, yes — PKI was actually around for quite a while before anybody noticed this gaping flaw in it's infrastructure. For this reason, most browsers will only permit a certificate "depth" (the number of certificates between the presented certificate and the root certificate) of 1 unless the key usage extension if present.


  1. X.509 Specification
  2. SHA-1 Specification
  3. TLS 1.2 Specification
  4. Implementing SSL/TLS Using Cryptography and PKI

Add a comment:

Completely off-topic or spam comments will be removed at the discretion of the moderator.

You may preserve formatting (e.g. a code sample) by indenting with four spaces preceding the formatted line(s)

Name: Name is required
Email (will not be displayed publicly):
Comment is required
Julia, 2013-01-21
perfectly. It informational resource, I'll bookmark it and visit it again!
Sander, 2013-03-25
"The public key is used to do the encrypting, and the private key is used to do the decrypting." isnt that the other way around?
Josh, 2013-03-25
As confusing as it seems at first - yes, it is the case the the public key is used to encrypt and the private key is used to decrypt. When you create a keypair, you _publish_ the public key. Then, when somebody wants to send a message to you, they use that to encrypt it.
Sander, 2013-03-25
It is correct indeed, nevermind :]
Josh, 2013-03-25
Just saw this comment after I posted my reply - neverminded (nevermound?) ; )
Cheyenne, 2013-07-01
You are so awesome for helipng me solve this mystery.
TrueLink, 2014-04-10
This is a great article and explanation. Thanks for the read.
Security, 2014-09-15
the signature of a certificate is generated from the hash of the certificate (without signature of course) encrypted by its CA's private key, not public key described in this article. This article is correct for verifying a certificate's signature: decrypting the signature with its CA's public key (e and n) and compare the resulting hash with the hash value calculated over the certificate.
Josh, 2014-09-16
Well, you're correct - when a CA signs a certificate, it performs an RSA encryption of the certificate's hash using its own private key (which is verified later using the public key), but I don't see exactly where I said otherwise. Which part are you referring to?
Yuri, 2015-03-05
The whole thing is signed by "Verisign Class 3 Secure Server CA - G2"'s public key and the signature is shown at the very bottom (and is even longer than the public key modulus!)
Resercher, 2015-10-30
Hi Josh thanks for the artical- This is btw where you saing its signed by public key you should say by private key

whole thing is signed by "Verisign Class 3 Secure Server CA - G2"'s public key and the signature is shown at the very bottom (and is even longer than the public key modulus!)
Josh, 2015-12-28
Sorry about that, you're correct. I've fixed it in the text.
Varun Chadha, 2014-09-19
1) For the RSA invariant it is specified that ((me)d) % n = m. However, E(P,k) = (me)%n and D(C,k)=((me)%n)d%n). Does this imply ((me) % n)d % n) = ((me)d) % n? 2) For validation of public key we are sending a signature with some data encrypted using private key along with the plaintext data which the holder of public key can use to verify. However, isn't this insecure as eavesdropper may have replaced the public key at first place, and then replaced the signature as well. In this case holder of public key(sender in this case) will never get to know the real receiver. How do we handle this scenario?
Varun Chadha, 2014-09-19
Please ignore (2).
melvin, 2015-03-08
necesito k me ayuden con la certificacion para poder tener permiso a barios sitios wet
Josh, 2014-10-03
1) Yes, what you're asking here is whether or not the modulo operation (%) is distributive over exponentiation, and it is (RSA does rely on this). The wikipedia page on finite fields includes a technical proof.
Yuri, 2015-03-06
Can you pls, briefly explain how in practice hash is created from a certificate minus signature? does it mean the hash is computed from the output of openssl x509 -in cert.txt command or so minus signature?
Yury, 2015-10-20
I was a bit confused by that section as well. The hash is computed over everything except the hash algorithm and signature. You can take a look at the following for the details (links not allowed):

and section signatureValue
rturnbul, 2015-04-15
In this way, if you get a public key from Bob, you just need to check with the trusted authority whether or not this is really Bob's private key. This seems confusing ... shouldn't it be "......really Bob's public key"?
Josh, 2015-04-23
You are correct, my mistake. I'm sorry - that's an embarrassing mistake on my part. I've corrected it and added a note; thank you for bringing it to my attention.
Matt, 2015-12-17
This is fantastic..the best article I've found.
I'm a little confused about one thing. Didn't you say the certificate is signed with the issuer public key at one point.
My understanding was the the issuer encrypts the child certificate with its own PRIVATE key and inspectors of the validity of that signature will decrypt with the issuers public key and check it's the same as the hash of the certificate they are validating?
Matt, 2015-12-17
Sorry I just noticed someone else has pointed this out
Dhiraj, 2015-08-16
Very nice article. Solved my mystery.
Cyprien, 2015-10-16
Very interesting , thnk you for explaining all that stuff
Shravan, 2015-11-24
Thank you so much.
vsn, 2016-02-09
Thanks for your great article. Seems to me the permanent solution is to sign the whole certificate instead of signing its hash. Sure, the signature will be as large as the certificate then, but how big is that? A few Kilobytes? A few tens of Kilobytes? This is nothing compared to the Megabytes of rich content that even the initial pages of many sites have.
Josh, 2016-02-17
Thank you for the feedback! Actually, there's no real inherent risk in signing the hash of the certificate rather than computing an encrypted form of the entire certificate file, assuming that the hash algorithm is secure enough to all but guarantee that collisions are impossible to engineer. In fact, there's a slight benefit in just signing (e.g. "encrypting" using the private key) just the hash rather than the entire file, since you're giving a potential attacker less redundancy with which to try to brute-force your private key with. The larger problem is really that of establishing trust relationships - if you look at the list of CAs that your browser trusts by default, it's a very, very long list, and there isn't much transparency into the security and business practices of all of the certificate authorities.
Jacob, 2016-03-25
this article is so close to helping this make sense for me, but I'm still missing something. in the first example, the self signed certificate, you decode the signature with the public key, and get "D95944F5BD92127092218F9F02C719C42386B499". what is this number? I was expecting to sha-1 something during the validation process?
Josh, 2016-03-31
Sorry, I guess I did sort of hand-wave over that part. You're correct: you'd SHA-1 something during the validation process; in particular, you'd SHA-1 the tbsCertificate part of the certificate structure itself. A certificate is defined by RFC 5280 as a structure containing three top-level fields: the tbsCertificate, the signature algorithm, and the signature. (See RFC 5280, section 4.1). The signature produced by hashing the bytes of the tbsCertificate (which is, essentially, "everything else"; tbs is short for "to be signed"). The specification is actually more complex than that, because the certificate is represented in ASN.1 format which allows for some ambiguity in its encoding, so it's the hash of the DER encoding of the tbsCertificate. RFC 5280 goes into more detail, as does chapter 5 of Implementing SSL.
Slim, 2016-04-23
Great article, thanks!
Rob, 2016-05-03
Thanks for a great article! I have a question. If I have PFX certificate with en exportable Private Key (issued by an Internal CA), should/can this Private Key be used for SSL and user authentication (SAML)? I have separate keystores for each?
Josh, 2016-05-20
Yes, you can do this - I do it all the time, for internal uses. The only trick there is that the certificate won't be trusted by a target that doesn't already trust the internal CA; in the case of SSL, for instance, you'll have to add the internal CA to your browser's trust store.
Rob, 2016-05-22
Thanks Josh. Do you know if there's a utility that can show how certificates in a chain are called and, if an error was encountered, which if the certificates caused it?
Josh, 2016-05-26
I think probably your best bet there would be openssl s_client.
Pol, 2016-08-05
Thank you for the fantastic article. I'm only confused at the ending:
"It would be trivial to generate a new certificate with a common name of, say "" and sign it with the public key in the now-trusted Amazon certificate, and your browser would silently accept it."
Shouldn't that say "...and sign it with the private key in the now-trusted Amazon certificate..."? But browser doesn't have the private key so this problem shouldn't exist. I'm missing something.
Pol, 2016-08-05
I mean the browser - and thus the attacker - doesn't have the private key.
Josh, 2016-08-18
Right - what would actually happen in this (hypothetical) case would be that the bad guy would get a signed certificate from a trusted root CA, one that your browser trusts, and then use that to sign a certificate that claimed to be, say, "". When the signed certificate for "" was presented to your browser, your browser would check the signature on the site certificate, see that it was legitimate, but that it was signed by an untrusted authority. So it would move one level up the chain, to the bad guy certificate, see that _that_ was signed by a trusted certificate, and that the signature was valid, and would then accept the whole chain silently.
Josh, 2016-08-18
Ah, I see what you're saying - and yes, I was a little sloppy with my phrasing. You're correct - the attacker in this scenario would have to use the private key corresponding to their certificate to sign a second, fraudulent, certificate such that it would validate with the public key of the trusted CA-signed certificate. To be even more rigorous - let's say that c denotes the trusted CA, a denotes the attacker, and v denotes the victim (so in this example c might be Verisign, a amazon and v ebay... if Amazon wanted for some strange reason to impersonate ebay), then each entity would have an RSA key of the form e,d and n as described at the beginning. So the CA has ce, cd and cn, and the attacker has ae, ad and an. The CA now signs the attacker's certificate by computing s_a = hash(a)^cd%cn, which is concatenated to the attacker's certificate a. The attacker forges a certificate claiming to be v and computes s_v = hash(v)^ad%an and attaches that to the forged certificate. The browser first validates s_v by computing hash(v)^ae%an and comparing it to the signature s_v in the forged certificate. They match, so the signature is valid, but not yet trusted. The browser then goes on to compute hash(a)^ce%cn and compares that with s_a. Now the signature has been validated, and is also trusted, because ce & cn were built into the user's browser. Unless, of course, the browser is smart enough to check the key usage extensions as it should.
Honey Keny Malviya, 2017-01-11
Can we generate a self signed ssl certificate through digital certificate. (Is it possible to sign a ssl certificate with a digital certificate?) ??
Honey Keny Malviya, 2017-01-11
Can we generate a self signed ssl certificate through digital Signature. (Is it possible to sign a ssl certificate with a digital Signature?) ??
Josh, 2017-01-13
Of course! All valid SSL certificates must be signed with another certificate - so, to solve this chicken-and-egg problem, there's a self-signed certificate (AKA top-level certificate) in every certificate chain. It's often useful to create self-signed certificates for testing purposes; you can do this on the command line like this:

    $ openssl req -x509 -newkey rsa:512 -keyout selfsigned.key -out selfsigned.cer -subj "/CN=localhost"
Anandan, 2017-03-07
It is a perfect resource to understand SSL from end to end.
Wesley Workman, 2017-04-18
Hey this is a very practical explanation of what's happening. I wanted the specifics, without reading the full SPEC. That's exactly what I got here. Thanks!!
Al, 2017-09-15
To view security cert in Chrome 56 (2017)

keyboard shortcut:
Ctrl + Shift + i

⌘ + Option + i

adrian, 2017-09-23
Really good article that clearly explains the cert signing process. You mentioned that in your sample case amazon sent both the intermediate AND the server cert. I always thought the intermediate was installed separately from an actual live session. Have I misinterpreted it?
How would you set up your TLS server environment to send both certs during the handshake?
Josh, 2017-09-29
That's correct - Amazon sends both it's own certificate (the one whose common name is "") and the signing certificate of that cert (whose common name is "Symantec Class 3 Secure Server CA - G4" now - when I wrote this blog post, it was Verisign, but they've switched CA's since) in the TSL Certificate handshake message. Strictly speaking, the PKI concept allows an unlimited number of certificates to be presented, as long as the following are true: 1) each one correctly signs the previous one and 2) the final one is signed by a certificate that's already in the receiver's trust store. However, as I mention in the final two paragraphs above, browsers have to be careful which certificates they accept as being signing certificates. Most websites only return their own certificate and one intermediate certificate, which was given to them by their CA.

As far as how to set it up, that varies from one server environment to another. This list of certificates that each sign one another up to the root is called a "certificate chain" and so the Apache server, for instance, includes an "SSLCertificateChainFile" directive which points to a PEM-encoded list of certificates.
Rico, 2017-10-08
Hi there Josh! I hope you still have time to answer my question. Actually your article have answered my question about where to get the public key in verifying the SSL certificate being presented by a certain server. However, I was thinking about root certificate installed in my browser. In view of Verisign, is the public key in their root certificate applicable in verifying the intermediate certificate authority they issued to their to each client they have?
Josh, 2017-10-11
That's correct: any certificate that is signed by Verisign's root must also be verified using the public key of its root certificate.
rico, 2017-10-13
So, why is there a need for intermediate CA certificate? Why not use directly the self signed root certificate to authenticate the digital certificate presented by the server. Is this just one of the many implementation of authenticating the digital certificate?

Sir, one more thing. How can different sizes of password becomes a fixed length key in symmetrical key encryption. Example, I can set different length of password in wifi but it becomes a fixed length key (i.e. TKIP, AES). Is the password related to the AES key? As I am writing this, I was thinking that this password is being use to the DH key exchange.

Thank you very much...
Rico, 2017-10-08
Another thing Josh...How were you able to show/view the public key in the self-signed root certificate. I tried viewing the trusted CA's certificate installed in my browser, but it only shows the Fingerprint.
Josh, 2017-10-11
Well, that depends on your browser/OS; I've tried it with IE, Firefox & Chrome on Windows, and Safari, Firefox & Chrome on Mac and Iceweasel and Chrome on Debian Linux and found a way to view the root certificate's public key, but the process varies on each. Which one are you using? On Chrome on Mac, you just go into root certificates and bring one up; the publc key is in the popup box toward the bottom.
rico, 2017-10-13
I saw it, thanks a lot. I needed to click the the Public Key entry so that the value will appear below.
My Book

I'm the author of the book "Implementing SSL/TLS Using Cryptography and PKI". Like the title says, this is a from-the-ground-up examination of the SSL protocol that provides security, integrity and privacy to most application-level internet protocols, most notably HTTP. I include the source code to a complete working SSL implementation, including the most popular cryptographic algorithms (DES, 3DES, RC4, AES, RSA, DSA, Diffie-Hellman, HMAC, MD5, SHA-1, SHA-256, and ECC), and show how they all fit together to provide transport-layer security.

My Picture

Joshua Davies

Past Posts