When thinking of certificates, I like to compare them to a passport or driver's license. When you hand your ID to a police officer they will:
- Check for validity: Inspect the ID to ensure that it appears authentic; matches what they expect your country's ID to look like, has no evidence of tampering, is not expired, etc.
- Check that you are the card subject: Compare the photo against the person standing in front of them.
At this point they have "verified" your ID and can trust any additional information in it (ex.: Name, Date-of-birth, address, etc).
A TLS client validates a TLS server certificate in exactly the same two steps:
- Check for validity: Ensure that the certificate cryptographically chains to a trusted root, is not expired or revoked.
- Check that the server is the certificate subject: Do a "proof-of-posession" check (usually a digital signature) to ensure that the server has the private key matching the public key in the certificate.
At this point they have "verified" the certificate and can trust any additional information in it (ex.: the server host name in a DNS_Name SubjectAltName extension).
You say:
any specific identity of server is NOT being passed apart from the server url
The server has two pieces of identifying information:
- Cryptographic public key, which is in the certificate, which you trust to be not tampered with if the certificate chains properly to the root cert.
- The server URL.
So if both of those checks pass, then you know you are talking to the server with that domain name, as certified by the Root CA.
if a server is being authenticated just via a root cert, any other body (not ligitimate server) could present its cert and will be authenticated by my IoT device!
That is only true if your Root CA is issuing certificates for a given URL to people who do not actually own that URL. If that is the case, Stop using that CA, report them to the CA/Browser Forum, and find a more trustworthy CA to do business with!
Implementation notes:
Your crypto library does not know what URL you are trying to access, and therefore does not know if the DNS Name in the cert is expected or unexpected, but the application does! If you are using a framework or tool with an HTTP request API, it will likely do this check for you, though sometimes if you are working directly with a TLS library, you will need to write the code for the hostname check yourself.
Also, "trusting the root CA" is how PKI works. It's the only scalable model for trusting a server that you've never interacted with before. But maybe it's not for you. If your IoT clients are only interacting with a small number of servers, and you know at manufacture time what those will be, then you could look into certificate or public key pinning where you provision devices with a local database of servers and the public key that you expect them to use.
