Which certificate should be used in an one-way SSL verification?

In one way SSL, the client always verifies the server certificates and the server never verifies the client certificates. Below is the description of the steps involved in establishment of connection and transfer of data between a client and server in case of one-way SSL:

  1. Client requests for some protected data from the server on HTTPS protocol. This initiates SSL/TLS handshake process.
  2. Server returns its public certificate to the client along with server hello message.
  3. Client validates/verifies the received certificate. Client verifies the certificate through certification authority (CA) for CA signed certificates.
  4. SSL/TLS client sends the random byte string that enables both the client and the server to compute the secret key to be used for encrypting subsequent message data. The random byte string itself is encrypted with the server’s public key.
  5. After agreeing on this secret key, client and server communicate further for actual data transfer by encrypting/decrypting data using this key.

Now i create an instance for one-way SSL verification:

acme.sh --issue --dns dns_cf -d domain.com  --server letsencrypt
ls  /home/acme/.acme.sh/domain.com/
fullchain.cer     domain.com.conf  domain.com.csr.conf 
ca.cer  domain.com.cer  domain.com.csr   domain.com.key

I save "fullchain.cer" and "domain.com.key" for verification in server side.Now there are three cerfiticates in fullchain.cer:

The first is domain name certificate as same as domain.com.cer
The second is the intermediate (R3)
The third is the cross-signed root certificate (ISRG Root X1)

Which certificate--fullchain.cer or ca.cer or domain.com.cer ,should i choose to save in client side for the one-way SSL verification?
The material above say that to set the CA certificate fo verification,in my case there is no real CA certificate !

You shouldn't have to save anything (from the ACME provided certs) into any client.
Normally, clients have their own trusted root stores and trusted certs will chain to one of them.
Also, it is very bad practice to send (or use) a root that was provided by a server you are trying to validate.

Imagine you go to your bank and it sends you a cert and the root you need to use to know that is your bank!
[If you got into that cycle anyone could impersonate your bank and you would believe them]


Everything @rg305 said is essentially correct, I just wanted to add some more context that may help:

This is true, but a bit misleading. The current industry standard is for Operating Systems to maintain a Trusted Root Store (which receives security updates), and for clients to utilize those roots. The industry is shifting a bit: Mozilla ships Firefox with it's own Root Store and Google has announced Chrome will be doing the same; several programming languages use their package management systems to ship updated Root Stores as well (such as Python using PyPi to ship Mozilla's root store as the Certifi pacakge certifi · PyPI ).

For 99.9% of use cases, this is true. The client should either have it's own root store or, more likely, rely on the Operating System (or a programming library's) root store.

In the very unlikely chance that you are developing your own client from the ground up:

  1. Your best option would be to rely on the Operating System's Trusted Roots OR a packaging manager's root store library.
  2. If you do need to include a root, you should include both the "ISRG Root X1" and "ISRG Root X2" certificates from Chain of Trust - Let's Encrypt, as well as the expired "DST Root CA X1" certificate. This is because your client must be able to adapt to LetsEncrypt potentially issuing certificates and fullchains that connect to any of these. The roots may change in the future as well.

This is essentially an intermediate certificate. This certificate has the same payload as "ISRG Root X1", but is signed by the expired "DST Root CA X1" and is provided for situations where the "ISRG Root X1" is not in the operating system's root store, but the DST is. While the DST is expired, most modern SSL libraries will ignore it and build their own trusted path to X1 (Domain Certificate > R3 > ISRG Root X1); older Android devices do not have X1 and do not check the expiration date of roots - so providing that chain makes things work on Android.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.