Home > Enterprise >  How SSL Certificates (CA) are validated exactly?
How SSL Certificates (CA) are validated exactly?

Time:11-06

I am searching the algorithm about how SSL validation process is performed, but almost everywhere, they explain the certificate validation step as "certificate is checked by client" or something like that, but I wonder what is the scenario behind this.

What I know is:

  1. When the client receives a copy of the certificate that belongs to which website/server you wanna attempt to handshake, there are some indicators that shows the public information of webserver (I think this is for matching the entries in your cached certificate entries, which your browser has installed.)

  2. Once the client matchs a cached-certificate with the webserver's one, it starts validating it. It uses the public key of cached-certificate to decrypt the signature of webserver's one.(? [Not sure this because public keys are used to "encrypt" the data, not decrypt. Also this step may be totally wrong.])

  3. Once it decrypts, it compares the signature between cached one and webserver's one. If it is same, certificate is valid.

  4. I also heard about chains. I really wonder how a chain is known, and how to determine if the webserver's certificate just belongs to a chain.(?)

How SSL certificates are checked by client? I need the answer as step by step and clarified. Thanks :)

Edit:

I think the public key here is used for "decrypting" instead of "encrypting". So a public key is not responsible for encrypting everytime, it can also decrypt and don't encrypt some data. The magic here is that since the public key decrypts here, if you want to fake the certificate, you should have that CA's private key to apply the changes as encrypted (because only private key can encrypt the data). But now, another question comes... What if we decrypt it using webserver's public key, then change the entries in the signature, then encrypt it again using our own private key (we generate it manually, it doesn't belong to server.), which actually make us behave like a CA; and finally overwrite the certificate to hold our own public key which is able to decrypt the data encrypted with our own private key?

CodePudding user response:

There is differences between Encryption and Signature.

Public Key is used by the client to encrypt data that only the server can decrypt with the Private Key of the server.

Public Key is used by the client to verify the signature of the data send by the Server that can only be signed by the Private Key of the server.

When the client wants to access a server, the server send you a certificate containing a public key. The client usually the web browser will check in his integrated CA's list certificates if it contains it.

  • If it contains it, the client continue and get the CA(Certificate authority)'s that authorized this certificate.
  • If it not found but the verification of the signature pass, the client will get a warning saying that the certificate is probably self signed and can be malicious.
  • If the client can't verify the signature, it means the certificate is not valid.

for the chain of trust you can check wikipedia : https://en.wikipedia.org/wiki/Chain_of_trust

you need to be in this chain of trust to be register in the web broswer integrated "database" of CA's.

Hope it answers your question, best regards,

M

CodePudding user response:

Put it simple:

Private Key -> Decrypt and Sign
Public Key -> Encrypt and Verify

Certification Authority

Is the authority that signs and guarantees the authenticity of the certification. If you trust the CA, then you trust also its certificates. It's the same for friends: if you have a friend that you trust and this tells you "I have a friend that I trust", then you also trust the friend of your friend.

Chain of Certificate Authority.

You can have multiple intermediate CA, for example, you can have

  • Root Certification Authority
    • Intermediate Certification Authority for WebServer signed by Root Certification Authority

      • Web Server Certificate signed by Intermediate Certification Authority for WebServer
    • Intermediate Certification Authority for signing code, signed by Root Certification Authority

      • Etc

Why?

Because in case one of the intermediate authorities is compromised you can revoke only its child certificates.

At the enterprise level, each CA has a different level of security, for example, the Root Certification Authority can be stored inside a safe and used only when there are two o more admins.

For the intermediate, instead, maybe only one Admin can manage it.

References
How SSL Works
How HTTPS Works
Wht digital certificates

  • Related