Blame
| d7157a | Samuli Seppänen | 2025-02-28 13:53:37 | 1 | # What are certificate chains? |
| 2 | Certificate chains are (daisy) chained certificates. They are most often used in secure web servers, where the 'root CA' is a globally known CA certificate , such as GlobalTrust or VeriSign. |
|||
| 3 | ||||
| 4 | A certificate chain can be depicted using ASCII art: |
|||
| 5 | ``` |
|||
| 6 | root-CA |
|||
| 7 | + sub-CA1 |
|||
| 8 | + sub-CA2 |
|||
| 9 | + SSL server certificate |
|||
| 10 | + SSL client certificate |
|||
| 11 | ``` |
|||
| 12 | The dependency of the "SSL server certificate" on the "sub-CA2" certificate, which in turn depends on the "sub-CA1" certificate which depends on the "root-CA" certificate is what makes this a certificate **chain**. |
|||
| 13 | ||||
| 14 | # Certificate chains versus stacked certificates |
|||
| 15 | A certificate chain has a dependency between the different elements. A stacked certificate means that a bunch of certificates have been stacked together, without any interdependence between them. OpenVPN supports both. When using certificates signed by multiple CAs it is often sufficient to simply stack the different CA certificates together: |
|||
| 16 | ``` |
|||
| 17 | $ cat ca1.crt ca2.crt ca3.crt > stacked.crt |
|||
| 18 | ``` |
|||
| 19 | and use them in the OpenVPN configuration using |
|||
| 20 | ``` |
|||
| 21 | ca stacked.crt |
|||
| 22 | ``` |
|||
| 23 | ||||
| 24 | **Important notice**: All certificates which are signed by **any** of the CA certificates found in the 'stacked.crt' file are considered valid. Thus, be very careful when adding CA certificates to a stacked certificate. |
|||
| 25 | ||||
| 26 | Certificate *chains* are very similar but here the client (or server) certificate itself and its sub-CA certificates are stacked together, as will be explained in the following section. |
|||
| 27 | ||||
| 28 | # How to use certificate chains in OpenVPN |
|||
| 29 | ||||
| 30 | 1. Consider the following CA setup: |
|||
| 31 | * the 'root CA' certificate is 'ca.crt' |
|||
| 32 | * the server certificate is signed by the root CA |
|||
| 33 | * a separate sub-CA or intermediary CA is created, which is also signed by the root CA |
|||
| 34 | * the client certificates are signed by the sub-CA. |
|||
| 35 | This can be depicted using some ASCII-art: |
|||
| 36 | ``` |
|||
| 37 | ca.crt --- server.crt |
|||
| 38 | +-- sub-ca.crt --- client.crt |
|||
| 39 | ``` |
|||
| 40 | ||||
| 41 | 2. Create a chained certificate by concatenating the 'client.crt' and 'sub-ca.crt' file in the right order: |
|||
| 42 | ``` |
|||
| 43 | $ cat client.crt sub-ca.crt > chained.crt |
|||
| 44 | ``` |
|||
| 45 | ||||
| 46 | 3. Configure the OpenVPN server using |
|||
| 47 | ``` |
|||
| 48 | ca ca.crt |
|||
| 49 | cert server.crt |
|||
| 50 | ``` |
|||
| 51 | ||||
| 52 | 4. Configure the clients using |
|||
| 53 | ``` |
|||
| 54 | ca ca.crt |
|||
| 55 | cert chained.crt |
|||
| 56 | ``` |
|||
| 57 | ||||
| 58 | The server will accept connections from the client even though it does not directly have access to the 'sub-ca.crt' file. This is very similar to how a web browser trusts a secure website, where the certificate chain has been signed by a CA certificate that the web browser knows (e.g. VeriSign, GlobalTrust, others). |