What are the disadvantage of not using intermediate and root file while uploading ssl certificate to nginx?

Question

I was installing ssl certificate in nginx server. We were given 4 files. I could not note what contained in those files, but I vaguely remember their name.

1. root.txt
2. intermediate.txt
3. private.txt
4. certificate.txt

But I used only private.txt and certificate.txt to upload certificate to server.

https://www.thesslstore.com/knowledgebase/ssl-install/nginx-ssl-installation/

I was reading this blog and it included intermediate certificate as well.

What are the disadvantages of not using the intermediate.txt file?

The certificate was valid when I tested it. Is it less secure that way? If yes, why?

PS I used these commands to verify the hash generated by both were valid.

$ openssl x509 -noout -modulus -in certificate.crt | openssl md5
$ openssl rsa -noout -modulus -in private.key | openssl md5

Answer 1

What are the disadvantages of not using the intermediate.txt file?

RFC 4158 mandates that the leaf certificate and all intermediate certificates must be included in the certificate chain served by the server. (The root certificate is optional, because the client needs to have the root certificate stored in its trust store irrespectively in order to authenticate it).

So, one disadvantage of not including the intermediate certificate in your certificate chain is that you would not be complying with RFC.

Having said that, there are many sites do not include the intermediate certificate in the certificate chain, and these sites still work flawlessly with most browsers. This is because modern browsers are very agile when it comes to 'fixing' broken certificate chains. Many browsers have a local cache where they store widely used intermediate certificates. Also, most CA's nowadays issue certificates which use the AIA extension to point to a URL where the next certificate up in chain can be downloaded. So, browsers can often compensate for missing (or expired) certificates in the certificate chain using one of the above methods (in fact, this is what makes certificate cross signing possible).

However, other web clients besides browsers (such as command line clients like curl and wget, and libraries used with programming tools to build API clients, etc.) may not be as agile. So, it's best to include the leaf certificate and all intermediate certificates in the certificate chain to be compliant with RFC, and it can't hurt to include the root certificate as well.