1

Background: I'm using the curl library to upload files via TLS to a server with a DigiCert certificate.

Phenomenon: During the handshake phase, the server sends a Hello message and returns the certificate chain information, which is parsed to find that the returned certificate chain contains three certificates: one is the user certificate, the intermediate certificate is signed by DigiCert, and the root certificate is signed by VeriSign.

Q: When the device validates the server certificate using DigiCert, the debug message shows that the validation was successful and the file was uploaded, but I want to know if the certificate issued by VeriSign is part of the certificate chain validation.

Improve this question

1 Answer 1

Reset to default
1

The certificate signed by VeriSign is most definitely part of the certificate validation.

The certificate is a root certificate that you trust because you have it installed in your system. These trusted certificates are preinstalled in your computer by your OS's distributor.

Root certificates are necessary because they provide a source of trust in the certificate chain. That is, you trust the user certificate because it has been signed by DigiCert, and you trust DigiCert because it's certificate has been signed by VeriSign, which you trust because you trust VeriSign.

There is nothing special about VeriSign. They are an enterprise whose business is precisely being trusted. They give certificates to people ad enterprises that prove that they are who they say they are, and we all trust that they do their job well (i.e. that they will only give a certificate in DigiCert's name to the actual DigiCert, not to anybody else).

Root certificates are necessary in TLS validation to avoid MITM attacks. If there were no root certificates, when a website gave you a certificate for their domain name, you wouldn't know whether it was the actual website that has signed the certificate, or someone else posing as the website (a Man in The Middle). VeriSign takes care of that identity verification for you (or rather, they give a certificate to DigiCert to do it by themselves).

If you didn't trust the root certificate, or the certificate given by a website was self-signed, expired, not yet valid or in any other way not trustable, curl would refuse the TLS handshake and throw an error.

Improve this answer
3
  • I work on the device side and the server will return the url based on my request. I used the WireShark to check the CA chain returned by the server, and found that the server responded with different CA chains. Details: Server 1: Returns a chain of three CAs , user CA , Intermediate CA (DigiCert), and root CA(VeriSign) Server 2: Returns a chain containing two CAs, the user CA and the certificate (DigiCert). When the VeriSign CA is stored on the device, it is found that server 1 is successful and server 2 is failed. When the DigiCert CA is stored on the device, both servers succeed.
    – Abner Sun
    Commented Sep 12, 2023 at 3:11
  • Comparing the CA of the two servers, the content of each CA is the same. What confused me was: 1. The server will return the url based on my request, and the server is designed for load balancing, but why will it return a different certificate chain? Is this kind of design common? 2 When a DigiCert certificate is used on the device, server 1 can successfully validate it. However, the intermediate certificate is signed by DigiCert and the root certificate is signed by VeriSign. The device and server root certificates don't match, so why do they pass?
    – Abner Sun
    Commented Sep 12, 2023 at 3:12
  • @AbnerSun To the first question, if you've got the DigiCert CA stored in your computer as a trusted root CA, then you don't need other root CAs to verify it, as you have specifically trusted it. Else, if the chain does not contain a root CA you can trust, the handshake fails. If, you trust two certificates in the chain then it will obviously pass. I would advise you not to install/uninstall root CAs in your PC unless you know what you are doing.
    – ComputerUser121212
    Commented Sep 12, 2023 at 10:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .