Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As far as I know,

when I request a certificate from Verisign (for example), and after they approved that me is me, they create a certificate (for me) which contains the digital signature and public key.

The digital signature is a data which was created (not encrypted!) by their Private key over my certificate Data.

Now, a client connects to my site (which has a SSL certificate).

  • He reads the digital signature (from the certificate)
  • He knows which algorithm used to create this signature, and he runs the hash again over my certificate data
  • Client uses his public key (in his store) of Verisign to decode (not decrypt) the digital signature
  • if there is a match - all fine.
  • client generates a random number, encrypts it with my public key, and my server accept it and from now on - we are in symmetric mode.

I have the following questions:

  1. Was I right ?

  2. Verisign creates the digital signature over my certificate data. Which data?

  3. The digital signature was created by what operation(?) over my certificate data? (Is this hashing?)

(I am not a cryptographer, but a programmer who wants to understand this stuff.)

share|improve this question
"client generates a random number, encrypts it with my public key" That's only true for plain RSA suites. Stronger suites use a different algorithm with temporary asymmetric keys that get signed with the long term key. – CodesInChaos Nov 12 '12 at 7:52
hi @CodesInChaos thanks for information :-) – Royi Namir Nov 12 '12 at 7:55
@CodesInChaos Iread your blog a bit , does it have the information answering my question ? how Can I contact you ( if theres a way of course) – Royi Namir Nov 12 '12 at 8:21
My blog doesn't contain anything on SSL. You should read How does SSL work? on security.SE. If you want to contact me, the info is in my profile. – CodesInChaos Nov 12 '12 at 11:01

1. Was I right?

Pretty much. I want to add something to help clarify though: The Verisign public key in his store is of the Verisign CA (It is also stored in the form of a certificate). Also I think this process would qualify at decryption, no?

2. Verisign creates the digital signature over my certificate data. Which data?

I'm not really sure what you mean here, but I'm guessing you are referred to the public keys store.

Basically the browser/OS have to trust a Certificate Authority (in this case Verisign). This trust is implemented by putting Verisign certificate including a public key inside the software. The corresponding private key will then be used to digitally sign certificates of websites that buy Verisign services. Because the browser have the public key, it can verify anything that Verisign signed using the corresponding key, hence the strength of this model.

A question might pop: Whose private key is then used to sign the certificate that is stored in the browser? It is usually self-signed (Use the very corresponding private key) or sign by a public key that is eventually self-signed. There is no way to verify self-signed certificate, hence the trust must be made in advance (by putting certificates in store).

3. The digital signature was created by what operation(?) over my certificate data? (Is this hashing?)

What Verisign (and other CA) do is generated a private/public key pair (this process is called key ceremony). They then sign certificates of websites using the private key (Which is only done once per website), this process create a certificate that is signed by Verisign, which is then passed to the browser. If you're asking about the algorithms, basically they hash the certificate content and then encrypt the hash with the private key, so typically there's usually 2 algorithms used, one for hashing (MD5, SHA, etc.) and one for encryption (RSA, DSA, etc.)

Edit: Read comments to find out more, but I think basically this explanation is correct.

share|improve this answer
For RSA and other signature schemes based on trapdoor one-way functions, signature verification is a bit similar operation to encryption (not decryption, it uses the public key). For other schemes, signature verification has nothing to do with encryption or decryption. – Paŭlo Ebermann Nov 12 '12 at 19:16
Thanks for the feedback. Could you elaborate a bit more on which other schemes that do digital signatures verification differently? Also I thought that RSA scheme is the most popular one, am I correct on that? – Pham Trung Nghia Nov 13 '12 at 6:26
Have a look at DSA, for another popular one. (It was explicitely made to not be usable for encryption purposes.) – Paŭlo Ebermann Nov 13 '12 at 9:00

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.