Certificates Simplified
Table of Contents
Foreword
Security is a vast and evolving field that can take a lifetime to study. However, problems in security can often boil down to three domains that must be addressed:
- Identification: a service or person is who they say they are.
- Reliability and verification: the data sent out is exactly the same as the data that is received.
- Encryption: Only the sender and the intended recipients know the true contents of the data.
In this article, we’ll be looking at identification, and how this is addressed in the modern web with certificates.
Certificate Examples
Throughout this article, we will be using the following three certificates:
For your convenience, a rendering of each certificate is provided below (using
the openssl
utility):
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
46:d6:23:ba:15:7f:af:a8:ad:26:0d:fc:27:5b:d7:01:cf:59:a1:57
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, ST = Texas, L = Austin, O = Acme CA, OU = Security, CN = Acme Root CA
Validity
Not Before: Apr 13 02:53:17 2019 GMT
Not After : Apr 8 02:53:17 2039 GMT
Subject: C = US, ST = Texas, L = Austin, O = Acme CA, OU = Security, CN = Acme Root CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit)
Modulus:
00:d2:c0:09:fd:a5:32:b0:eb:b4:88:4c:86:00:49:
d5:d5:52:66:f6:e8:ea:78:41:2b:8c:92:5b:da:3c:
c1:5f:38:53:fc:b4:fc:4e:43:19:75:da:14:5d:01:
5b:ca:2f:1d:d6:64:a3:d9:d4:5e:b2:18:da:56:c8:
54:d9:34:1f:74:f8:47:4f:ed:57:0a:7c:5a:34:9b:
79:8c:c2:da:93:28:6d:a3:a7:67:0e:18:8d:98:11:
0d:c1:b5:da:c6:f1:65:cf:c3:6d:a9:ba:88:a3:5f:
b2:fc:88:bf:c3:ac:5c:50:73:d8:74:61:5c:d7:27:
18:27:c1:f6:69:34:82:ed:75:83:88:b9:e3:7c:34:
60:e3:9a:47:70:68:31:c5:28:6f:b5:79:6d:68:16:
97:15:6b:3e:ae:50:b0:f9:d7:d9:5d:45:d3:47:8d:
b6:5d:9b:fd:89:ea:51:17:fa:7b:2d:1b:8b:5d:01:
ed:ab:2d:c2:62:fa:b1:3e:90:ce:f1:9f:a5:5a:18:
6b:84:e8:9d:2d:10:5e:06:d5:32:46:d2:62:8d:bd:
49:29:39:72:cd:de:12:20:bf:1a:fa:dc:d4:75:31:
17:bd:ac:d6:24:55:b2:94:c8:04:a2:da:16:6a:72:
7d:1e:3a:4f:55:0b:90:9f:ae:9d:03:6b:d7:25:85:
e0:38:e8:8e:8e:09:1f:c1:24:a9:ca:07:7d:30:8a:
57:5e:3c:71:58:62:e9:e0:8c:81:e6:9a:f3:b1:e5:
30:64:aa:e5:75:fb:b3:c5:93:83:4a:61:a7:4f:dc:
1e:b2:3f:96:d2:e2:95:b5:42:b1:2a:a2:c0:62:ce:
c6:9c:aa:e4:37:86:54:f6:ec:ef:4f:25:e8:49:29:
88:54:dc:4a:bc:90:f1:df:91:c8:1c:93:14:76:50:
ec:66:b5:04:ce:d8:21:72:1e:d2:b1:07:68:a1:e8:
02:68:2a:7a:7c:ea:b5:e9:b4:bb:e7:a1:38:5b:14:
2a:4d:ed:9c:da:9f:f5:dd:28:94:1e:d1:2c:d4:45:
52:aa:8a:b1:14:67:3b:db:c5:62:87:8c:fb:01:6f:
3a:cd:c8:b0:c2:ee:c7:5a:2d:ef:f3:f8:17:f2:e1:
f9:3e:17:fb:9b:ae:97:ff:e0:ec:11:b5:c4:fe:a3:
1e:6d:a3:38:a9:24:d9:9c:e8:76:05:dc:1d:6e:21:
c5:78:e7:dc:22:24:b9:89:c6:c6:5c:02:97:42:d4:
9c:bc:5a:cb:10:fc:4a:81:96:4a:43:4e:53:04:71:
00:c3:e4:7d:45:40:e0:5e:80:79:ed:ee:4f:b6:d6:
5d:38:b6:48:96:21:c8:2e:f8:28:54:8a:49:26:ac:
50:c1:31
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
F0:0A:43:99:C6:DF:AD:50:C4:67:F9:7D:6D:62:97:6D:DD:23:83:49
X509v3 Authority Key Identifier:
keyid:F0:0A:43:99:C6:DF:AD:50:C4:67:F9:7D:6D:62:97:6D:DD:23:83:49
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
Signature Algorithm: sha256WithRSAEncryption
4c:16:1e:80:ef:ee:21:f7:5d:ee:a4:3c:bc:60:a7:f4:d3:b3:
6c:3e:70:05:70:d2:45:6d:7b:ed:65:94:84:8b:c6:eb:f5:6b:
a4:d8:55:9b:57:ff:de:c2:85:19:4b:ae:d4:a0:84:38:77:3e:
61:dc:5d:e7:90:23:d9:f7:29:81:c9:7e:84:b1:7a:d9:2b:04:
80:92:7c:90:ef:59:ff:75:8b:68:32:da:98:36:78:3c:3b:0e:
43:99:cd:ae:7a:72:d4:d3:7b:4b:44:d0:b0:4b:e1:27:c5:72:
fa:1b:39:23:e3:5a:65:cd:7d:50:c1:6a:2e:60:51:39:c8:11:
6a:f7:78:4b:19:eb:8a:9e:59:92:30:2e:ef:30:5f:33:4c:98:
a0:f7:ff:8b:ba:5d:a6:c0:3e:7f:99:c7:cf:37:78:cc:5e:74:
bb:f2:c4:b2:a7:3a:5f:0c:34:59:fe:66:44:ce:31:f1:51:c2:
fb:51:9a:88:74:a1:f0:8e:b4:f3:61:1c:22:15:80:b3:e1:d7:
2e:3c:ca:dd:58:b7:20:ba:48:82:fe:e4:a4:c2:24:94:83:09:
b8:84:a0:4c:3e:15:13:87:e3:38:57:9e:a8:1a:c8:77:89:f8:
bc:8d:73:41:04:05:b0:fe:f5:86:9c:4f:47:f7:d7:23:44:bd:
ce:1f:97:24:a9:64:59:88:e8:7f:11:4f:71:9f:09:f1:22:62:
be:b6:99:a6:77:65:5d:0a:5f:0f:97:96:6d:73:e5:f0:bb:2a:
66:f8:f6:d4:f3:59:85:f6:3d:47:ad:62:80:d7:ef:16:a1:41:
ce:4c:d8:ee:49:4b:03:6b:5b:0a:55:da:82:12:4c:35:5e:68:
39:02:ef:e4:7c:98:5b:c5:44:38:cc:0e:21:ab:6e:31:cf:9e:
88:1c:45:08:ae:d2:2d:cb:61:2b:50:a4:a2:55:c9:20:9a:31:
ae:86:aa:ff:79:86:6e:72:bb:9b:41:57:ff:21:39:18:5e:72:
79:25:cb:88:12:c4:df:a9:39:a0:0c:67:d1:25:74:d9:43:49:
99:be:91:db:7e:10:8b:4a:c0:6c:53:81:77:d0:db:57:fc:c7:
4f:bd:68:b1:b0:ff:9a:7f:bd:40:44:24:6a:8a:1c:cb:9f:89:
fd:57:7d:bc:49:94:ae:2e:1d:bf:ef:45:46:66:f8:5c:86:ac:
bb:f9:a5:8c:28:7a:39:08:f5:3e:58:fe:cf:41:7f:ea:4c:aa:
7c:e7:34:eb:a6:44:44:f2:2a:eb:64:d5:75:a7:56:0d:d9:25:
68:2f:70:ea:7a:f8:ec:4a:46:02:c3:da:a5:dd:a9:c8:4c:b2:
6d:1b:29:3f:48:2d:12:f0
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4096 (0x1000)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, ST = Texas, L = Austin, O = Acme CA, OU = Security, CN = Acme Root CA
Validity
Not Before: Apr 13 02:54:36 2019 GMT
Not After : Apr 10 02:54:36 2029 GMT
Subject: C = US, ST = Texas, L = Austin, O = Acme CA, OU = Security, CN = Acme Intermediate CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit)
Modulus:
00:c5:f7:82:43:2e:cb:ad:9f:f3:f8:18:ec:0d:36:
71:88:5c:4c:6d:d9:b0:e5:93:c7:8a:ac:2c:5e:ea:
ee:c4:b9:bf:5a:cb:2f:81:f3:0f:0b:a4:d5:41:f8:
67:97:13:42:40:a0:d9:73:fe:5e:15:7a:d8:8c:4b:
59:4f:9e:19:ed:95:61:a0:f3:07:ec:47:7b:9b:54:
02:d0:9c:6a:20:06:41:90:ca:37:5e:04:f4:4e:14:
01:5d:d3:45:08:f7:bd:19:85:66:be:88:a9:c8:06:
5e:c5:78:d7:47:d2:ff:9f:13:02:b3:9c:4a:47:45:
08:10:2a:93:c8:93:60:94:dd:68:bf:30:bf:93:36:
d1:d4:0d:a8:70:69:05:55:04:8a:f1:58:47:69:80:
5d:29:62:83:17:48:18:f8:cc:48:f7:a6:89:bc:32:
3f:81:e6:f6:84:0b:19:a1:87:e6:6c:61:3e:87:49:
1d:6d:9d:60:a4:97:32:bf:3c:a3:2d:5a:f3:09:82:
20:b8:41:84:c6:23:33:80:f3:93:0e:81:44:43:59:
57:53:86:81:3b:50:74:cd:b1:10:20:9e:cb:4b:55:
80:a5:d4:27:31:31:67:db:f6:32:b8:47:7c:19:94:
c1:fc:57:5f:44:c5:70:8c:ad:83:44:01:a8:76:bc:
8f:07:dd:1f:fb:96:8e:8c:65:e3:e1:6b:b4:b1:18:
d7:e0:9c:dd:42:f9:38:4e:1f:a6:5a:88:0d:64:79:
2d:8c:a2:ac:fa:9c:ab:23:eb:22:4a:fb:a5:29:3d:
3c:a8:6f:42:6a:12:f7:e5:f4:bd:72:1b:db:48:10:
4d:cf:7e:8e:2c:6b:85:32:84:5d:dc:e0:4b:5e:f1:
79:70:d9:98:95:f7:c6:bf:f1:da:ea:61:ab:9d:02:
29:71:4a:f6:fc:0b:ef:f1:e8:b0:77:df:f1:43:05:
40:bf:4b:62:79:a6:0a:a2:fc:c6:c3:2e:2e:c3:bc:
68:41:74:16:ab:80:eb:15:67:24:af:3d:14:22:58:
2f:93:3b:a4:62:58:b4:7c:95:11:b0:8e:4d:33:21:
55:b3:29:73:ba:a0:17:05:76:54:ac:b1:49:2b:13:
5d:7e:a3:ac:7b:ff:0d:6d:8f:cb:be:79:8d:40:8f:
4d:c3:05:7d:56:af:5b:61:2c:79:3b:1d:90:21:12:
0a:f2:40:54:f7:c4:7b:64:36:fb:45:18:49:ae:04:
1b:63:cc:91:96:09:5e:bb:dc:34:9f:82:07:9b:8e:
1b:d7:d7:68:7e:02:40:1d:31:bf:5a:a0:bf:a3:9c:
07:42:69:4a:77:df:90:9c:d7:14:34:50:96:ff:5c:
5e:67:f7
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
14:82:3A:09:76:FF:EA:7E:79:70:C7:03:6C:38:E7:9A:5D:CD:84:57
X509v3 Authority Key Identifier:
keyid:F0:0A:43:99:C6:DF:AD:50:C4:67:F9:7D:6D:62:97:6D:DD:23:83:49
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
Signature Algorithm: sha256WithRSAEncryption
b0:f4:e9:cd:b9:ab:2a:9c:e3:12:5e:ac:77:68:34:eb:ee:07:
01:76:3f:48:64:2c:61:f7:76:66:5d:a6:fc:38:ef:89:9e:0a:
de:d0:5d:bd:3f:cf:8f:18:f9:af:f1:a4:60:67:da:6a:fe:4f:
f9:14:c3:e2:11:dc:42:19:4e:e4:ad:98:2b:16:aa:4f:36:9a:
4e:44:e3:d3:df:4d:52:b9:d7:66:0d:62:e2:6b:88:2f:34:fb:
7f:5a:0e:b7:e0:b8:b9:bc:7e:7c:84:fb:20:49:ef:57:0d:b0:
f9:7f:a4:80:f0:da:f6:a2:4c:3a:d7:fb:05:84:d6:0e:02:25:
7a:77:42:ab:86:c0:93:e0:73:87:05:1c:81:c3:65:22:19:3c:
5e:55:32:20:5b:78:de:5b:38:52:eb:e1:81:9e:e5:59:4c:b7:
96:d2:ce:62:f8:2b:60:ad:5c:17:37:23:47:af:f4:40:44:00:
4c:88:0a:d3:26:ff:9e:30:15:19:54:80:9a:91:99:f0:39:fc:
31:e5:47:3e:c7:15:fa:8e:8c:22:53:7c:ee:de:0c:9f:3c:dd:
95:87:9d:01:3a:0b:0c:38:2f:f3:0c:cd:b4:54:b4:c7:8e:9c:
2c:67:7e:29:bc:30:a3:00:44:d7:26:3e:50:89:a0:40:17:29:
1b:48:7e:79:53:a6:8a:00:c0:3a:f1:02:bc:70:1e:ca:91:b0:
15:38:79:f6:14:32:86:69:a8:3a:29:01:1c:ce:a6:d4:3d:5d:
b8:a5:da:64:11:ef:74:87:8d:01:a7:08:db:f3:1e:59:f0:bf:
0a:17:6f:ad:b8:f8:54:78:2a:93:07:40:e9:9d:62:ab:b7:52:
38:5d:cf:eb:f1:b0:26:14:36:83:1f:d7:87:5f:6c:3c:c1:5b:
b6:aa:0c:49:e4:64:49:a0:4a:da:59:93:11:40:7e:24:8f:82:
90:24:76:7f:85:26:53:0e:2d:18:52:b7:3e:43:17:69:09:16:
55:51:0d:02:0c:8d:ca:93:60:72:e3:47:b4:40:76:1e:a8:8c:
78:16:52:db:ff:a6:ad:dd:17:b4:89:9c:58:85:75:48:bb:ea:
fd:be:c2:31:e9:41:a7:74:e5:cc:31:ba:b2:31:03:81:e1:48:
51:1a:20:d0:19:89:15:ed:06:b9:96:3f:47:2a:00:92:c7:7a:
78:07:f2:f8:6b:5d:1b:66:52:69:56:44:dc:b3:66:4a:f0:9d:
9c:81:75:3b:7c:dd:f5:28:87:ff:7a:c0:25:65:59:3f:aa:cb:
07:dc:7e:5d:78:8d:f3:97:6d:44:01:aa:12:4e:29:50:63:3d:
15:32:d6:3a:0a:d6:41:81
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4106 (0x100a)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, ST = Texas, L = Austin, O = Acme CA, OU = Security, CN = Acme Intermediate CA
Validity
Not Before: May 17 03:05:58 2020 GMT
Not After : May 27 03:05:58 2021 GMT
Subject: C = US, ST = Texas, L = Austin, O = Naughty Sysadmins, OU = Blog Archive, CN = Acme Server Certificate, emailAddress = nchambers@securitea.app
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:ab:b9:3a:c7:63:56:10:5f:c6:d1:54:fb:11:9f:
23:b9:f3:f6:39:a6:b1:fa:c7:b4:32:75:74:c8:95:
fc:4a:68:7d:2b:82:81:27:fd:4c:39:30:74:34:8c:
bf:b7:11:30:9a:9c:64:55:99:0a:77:3f:d3:74:ac:
17:4e:ad:8c:c6:84:53:30:fd:1b:01:a7:5d:51:93:
1e:4a:c0:2e:f8:65:9a:0f:a6:55:94:ba:c2:5d:39:
71:92:db:5f:05:48:9e:e9:32:2e:7c:d3:f3:43:f0:
f0:f6:24:56:2e:92:e8:c3:2b:96:e4:ab:40:a7:5b:
a3:6d:37:a8:3a:a0:89:89:16:1d:20:1e:28:6d:44:
25:da:88:51:b9:f8:5b:a3:60:21:0c:eb:32:5b:ed:
a2:84:9f:89:48:a0:33:54:5b:9e:15:e4:1d:17:b5:
81:9c:43:bd:21:55:76:4b:95:1c:61:8e:ea:28:2e:
b2:a3:58:a9:52:49:25:f6:3b:44:c0:cf:b6:d6:89:
22:24:3c:a4:f1:4d:4d:9f:69:6d:cf:6c:c5:07:26:
b9:70:74:97:e9:ac:a0:3f:c0:dd:41:9c:ae:b5:41:
80:6a:65:23:2c:2e:e9:94:9d:d1:91:8c:33:13:fc:
11:12:7a:c6:90:86:9b:bd:af:1d:dd:f7:7e:81:9d:
19:d3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
Acme User Certificate
X509v3 Subject Key Identifier:
83:27:BE:F7:CA:0C:28:33:74:F3:6E:B5:C6:D7:01:A6:A9:D4:AC:AC
X509v3 Authority Key Identifier:
keyid:14:82:3A:09:76:FF:EA:7E:79:70:C7:03:6C:38:E7:9A:5D:CD:84:57
DirName:/C=US/ST=Texas/L=Austin/O=Acme CA/OU=Security/CN=Acme Root CA
serial:10:00
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:acme.naughtysysadmins.com
Signature Algorithm: sha256WithRSAEncryption
2f:62:ed:a9:40:7e:7f:7c:f2:f9:41:ac:79:79:e8:f2:37:81:
5d:8e:c8:82:17:91:9c:d1:ff:d2:0f:b2:08:97:b8:d1:97:de:
a3:7c:2c:35:e6:3e:fb:c1:f3:0f:14:0e:d1:8f:99:21:39:eb:
8f:7d:30:a0:4f:9c:05:2d:a0:04:71:70:86:59:c8:25:8b:c0:
1c:0a:2c:9a:bf:0c:23:5e:25:53:e1:5c:48:bc:ee:37:8f:3d:
50:be:08:e2:fc:04:e3:22:d9:88:ab:0d:45:1c:fc:06:51:4d:
0c:b8:2b:2b:20:c1:75:42:3e:83:33:2a:4f:d5:af:f4:2a:91:
97:1c:07:4c:9b:a9:7b:fe:99:79:49:32:6d:3d:fe:5e:7e:c1:
f4:af:63:f1:27:b2:4b:94:51:07:57:eb:ca:ac:d0:5e:b5:b2:
34:3b:dc:07:30:e1:70:85:39:df:39:a8:57:d1:7c:4d:33:03:
a5:08:11:ab:c9:52:f4:c4:f2:86:56:25:f0:83:fd:35:71:4e:
36:e8:c5:65:3a:39:fa:62:ed:0c:1d:ef:49:5a:32:48:d8:99:
d4:83:d7:95:97:9c:6b:2a:ab:cf:7e:8e:15:51:c8:38:3a:01:
ee:95:99:c0:c7:ae:03:d6:a0:e3:fd:05:ac:22:27:e2:7f:af:
69:9b:89:9e:4e:0b:b5:65:b6:7c:b2:57:3e:f5:37:46:b2:cb:
9f:42:f3:fb:9c:be:5e:19:d9:c9:5e:d2:b3:4a:99:51:e2:40:
ad:b7:b5:61:1a:7c:af:c1:bd:b0:e2:14:91:df:85:f3:67:cd:
eb:2f:25:fb:6f:36:c5:81:85:86:0d:a3:1b:85:c7:fc:9f:8f:
f0:29:46:12:7f:a2:ef:a0:6c:a6:d7:48:58:66:88:d6:ee:70:
4d:fe:aa:af:72:0d:84:26:96:4a:26:2f:ab:24:a6:88:8a:90:
82:9e:7e:7d:00:0a:07:ab:8f:9b:8c:ba:3d:e2:11:7e:b0:7d:
29:6e:b0:64:4c:df:ca:23:3e:2b:e7:66:e0:23:df:c8:26:17:
9e:0b:2c:dd:1c:2a:fd:d6:40:b3:90:20:77:df:63:fd:32:90:
05:15:c8:c3:24:8d:b4:e4:eb:8a:da:ea:e8:65:2e:0d:65:a2:
bf:53:6c:fe:be:71:c6:5c:55:7c:18:c5:b0:8b:82:c1:c5:03:
30:20:b4:cf:d1:04:46:e0:48:f1:c9:a4:58:03:cc:45:95:6c:
ff:d7:2f:9f:15:72:04:47:3b:aa:3c:ea:f7:25:33:c0:77:9f:
c1:0a:c8:e2:f6:a7:00:56:87:af:11:70:12:5b:8c:0e:7a:fa:
60:07:9a:92:b7:c7:12:b5
What is a Certificate?
When two entities communicate using an unsecure protocol over the internet, it
is difficult for either end to verify who they’re talking to. For example, if
you visit hmpg.com in your browser, there is no guarantee you
actually made it to hmpg.com, since communication was done
over HTTP
. As HTTP
is a plaintext protocol, anyone between you and
hmpg.com (such as your ISP) could intercept these packets and
inspect, modify, re-route, or drop them. Secure protocols (such as HTTPS
)
partially remedy this by using certificates.
A certificate is an electronic document that verifies an entity is who they
claim to be. For example, if you visit www.google.com
(using HTTPS
), www.google.com sends you back a
certificate that your browser leverages to make sure you’re actually talking to
www.google.com. Each certificate is made up of several
properties that describe who it’s for, where it came from, how long it is valid
for, as well as many other aspects. Let’s take a look at each piece of a
certificate, using cert.pem
as an example.
Version
Version: 3 (0x2)
This refers to the version of the specification (X.509
) the certificate
conforms to. Version encoding starts at 0 (0x00), so version 3 (the current
version) is encoded as 2 (0x02). Any modern certificate will conform to version
3.
Serial Number
Serial Number: 4106 (0x100a)
The serial number is an integer used for tracking by the organization that created the certificate. It isn’t very useful to end users in most cases. The serial number is encoded in its equivalent hexidecimal representation.
Signature Algorithm
Signature Algorithm: sha256WithRSAEncryption
The signature algorithm field specifies what hashing function was used to sign
the certificate. This first signature algorithm field is just used to
verify that the hashing function is correct for the second signature field later
on. SHA256
is the weakest hashing function that is trusted in modern
certificates, and the most popular one used. While there are stronger hashing
functions supported, SHA256
is still a very secure (and fast) hashing
function. Older hashing functions, such as SHA1
or MD5
, should not be
trusted.
Issuer
Issuer: C = US, ST = Texas, L = Austin, O = Acme CA, OU = Security, CN = Acme Intermediate CA
The issuer field conveys who created the certificate (or in X.509
terms, the
organization that issued the certificate). The issuer is encoded in a format
known as a distinguised name, or DN. A DN is a combination of one or more
comma-separated key/value pairs. A key is usually one of the following:
- C (Country)
- ST (State)
- L (City)
- O (Organization)
- OU (Organizational unit)
- CN (Common name)
- emailAdress (Email address)
The Lightweight Directory Access Protocol (or LDAP
) uses DN’s as well, since
it comes from the same set of standards as certificates. However, a DN is much
more meaningful in LDAP
, as it is essentially an absolute path to the location
of a user in a directory. In the world of certificates, it isn’t nearly as
important what goes into the DN, but that the DN stays consistent. While our
example issuer DN uses all 7 keys, it isn’t necessary to do so.
Validity
Validity
Not Before: May 17 03:05:58 2020 GMT
Not After : May 27 03:05:58 2021 GMT
This field tells the length of time a certificate should be used for. If the clock on the machine validating the certificate is off, then valid certificates may not be trusted (as well as expired certificates being trusted). While one could issue a certificate for as long as they wanted, the Certificate Authority and Browsers (or CA/B) forum has decided to limit end-entity certificates to only 825 dys. Some authorities, such as Let’s Encrypt, only issue certificates that are valid for 90 days.
Subject
Subject: C = US, ST = Texas, L = Austin, O = Naughty Sysadmins, OU = Blog Archive, CN = Acme Server Certificate, emailAddress = nchambers@securitea.app
The subject field is exactly the same as the issuer field, except that it describes who the ceritficate is for. Again, it isn’t as important what the DN contains, but that it doesn’t change.
Subject Public Key Info
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:ab:b9:3a:c7:63:56:10:5f:c6:d1:54:fb:11:9f:
23:b9:f3:f6:39:a6:b1:fa:c7:b4:32:75:74:c8:95:
fc:4a:68:7d:2b:82:81:27:fd:4c:39:30:74:34:8c:
bf:b7:11:30:9a:9c:64:55:99:0a:77:3f:d3:74:ac:
17:4e:ad:8c:c6:84:53:30:fd:1b:01:a7:5d:51:93:
1e:4a:c0:2e:f8:65:9a:0f:a6:55:94:ba:c2:5d:39:
71:92:db:5f:05:48:9e:e9:32:2e:7c:d3:f3:43:f0:
f0:f6:24:56:2e:92:e8:c3:2b:96:e4:ab:40:a7:5b:
a3:6d:37:a8:3a:a0:89:89:16:1d:20:1e:28:6d:44:
25:da:88:51:b9:f8:5b:a3:60:21:0c:eb:32:5b:ed:
a2:84:9f:89:48:a0:33:54:5b:9e:15:e4:1d:17:b5:
81:9c:43:bd:21:55:76:4b:95:1c:61:8e:ea:28:2e:
b2:a3:58:a9:52:49:25:f6:3b:44:c0:cf:b6:d6:89:
22:24:3c:a4:f1:4d:4d:9f:69:6d:cf:6c:c5:07:26:
b9:70:74:97:e9:ac:a0:3f:c0:dd:41:9c:ae:b5:41:
80:6a:65:23:2c:2e:e9:94:9d:d1:91:8c:33:13:fc:
11:12:7a:c6:90:86:9b:bd:af:1d:dd:f7:7e:81:9d:
19:d3
Exponent: 65537 (0x10001)
The public key can have several roles, depending on what the certificate is used for. Two common roles for a public key are generally encrypting data (to be sent to another entity), and verifying a certificate chain (which will be discussed further later on) is valid.
X509v3 Extensions
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
Acme User Certificate
X509v3 Subject Key Identifier:
83:27:BE:F7:CA:0C:28:33:74:F3:6E:B5:C6:D7:01:A6:A9:D4:AC:AC
X509v3 Authority Key Identifier:
keyid:14:82:3A:09:76:FF:EA:7E:79:70:C7:03:6C:38:E7:9A:5D:CD:84:57
DirName:/C=US/ST=Texas/L=Austin/O=Acme CA/OU=Security/CN=Acme Root CA
serial:10:00
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:acme.naughtysysadmins.com
The extensions field allows an entity to specify further attributes that describe the certificate. Each extension is made of the following 3 parts:
- A unique object identifier (OID)
- A boolean value (true or false) representing if an extension is critical or not
- The value of the extension
If an extension is critical, and the system validating the certificate doesn’t recognize the OID, it must reject the certificate. If the critical field is missing from an extension, then it is not critical.
A certificate can only contain one instance of an OID. Some common OIDs you might find on a certificate include:
-
Basic Constraints: specifies whether a certificate can be used by a certificate authority to issue other certificates.
-
Subject Alternative Name: gives the exact list of entities a certificate can identify. For example, if you visit www.google.com, it must use the subject alternative name extension, with an entry for
www.google.com
. Looking at our examplecert.pem
, we can see that it can only be used to identifyacme.naughtysysadmins.com
. -
Key Usage: specifies what the public key of a certificate can be used for.
Signature Algorithm (Again)
Signature Algorithm: sha256WithRSAEncryption
2f:62:ed:a9:40:7e:7f:7c:f2:f9:41:ac:79:79:e8:f2:37:81:
5d:8e:c8:82:17:91:9c:d1:ff:d2:0f:b2:08:97:b8:d1:97:de:
a3:7c:2c:35:e6:3e:fb:c1:f3:0f:14:0e:d1:8f:99:21:39:eb:
8f:7d:30:a0:4f:9c:05:2d:a0:04:71:70:86:59:c8:25:8b:c0:
1c:0a:2c:9a:bf:0c:23:5e:25:53:e1:5c:48:bc:ee:37:8f:3d:
50:be:08:e2:fc:04:e3:22:d9:88:ab:0d:45:1c:fc:06:51:4d:
0c:b8:2b:2b:20:c1:75:42:3e:83:33:2a:4f:d5:af:f4:2a:91:
97:1c:07:4c:9b:a9:7b:fe:99:79:49:32:6d:3d:fe:5e:7e:c1:
f4:af:63:f1:27:b2:4b:94:51:07:57:eb:ca:ac:d0:5e:b5:b2:
34:3b:dc:07:30:e1:70:85:39:df:39:a8:57:d1:7c:4d:33:03:
a5:08:11:ab:c9:52:f4:c4:f2:86:56:25:f0:83:fd:35:71:4e:
36:e8:c5:65:3a:39:fa:62:ed:0c:1d:ef:49:5a:32:48:d8:99:
d4:83:d7:95:97:9c:6b:2a:ab:cf:7e:8e:15:51:c8:38:3a:01:
ee:95:99:c0:c7:ae:03:d6:a0:e3:fd:05:ac:22:27:e2:7f:af:
69:9b:89:9e:4e:0b:b5:65:b6:7c:b2:57:3e:f5:37:46:b2:cb:
9f:42:f3:fb:9c:be:5e:19:d9:c9:5e:d2:b3:4a:99:51:e2:40:
ad:b7:b5:61:1a:7c:af:c1:bd:b0:e2:14:91:df:85:f3:67:cd:
eb:2f:25:fb:6f:36:c5:81:85:86:0d:a3:1b:85:c7:fc:9f:8f:
f0:29:46:12:7f:a2:ef:a0:6c:a6:d7:48:58:66:88:d6:ee:70:
4d:fe:aa:af:72:0d:84:26:96:4a:26:2f:ab:24:a6:88:8a:90:
82:9e:7e:7d:00:0a:07:ab:8f:9b:8c:ba:3d:e2:11:7e:b0:7d:
29:6e:b0:64:4c:df:ca:23:3e:2b:e7:66:e0:23:df:c8:26:17:
9e:0b:2c:dd:1c:2a:fd:d6:40:b3:90:20:77:df:63:fd:32:90:
05:15:c8:c3:24:8d:b4:e4:eb:8a:da:ea:e8:65:2e:0d:65:a2:
bf:53:6c:fe:be:71:c6:5c:55:7c:18:c5:b0:8b:82:c1:c5:03:
30:20:b4:cf:d1:04:46:e0:48:f1:c9:a4:58:03:cc:45:95:6c:
ff:d7:2f:9f:15:72:04:47:3b:aa:3c:ea:f7:25:33:c0:77:9f:
c1:0a:c8:e2:f6:a7:00:56:87:af:11:70:12:5b:8c:0e:7a:fa:
60:07:9a:92:b7:c7:12:b5
At its core, a certificate is a container, holding a collection of identifying
data, and the digital signature. The digital signature is primarily used to
validate who issued the certificate. A signature is computed (in very rough
terms) by hasing the identifying data, then encrypting the result with the
issuing certificate’s private key. In the case of cert.pem
, SHA256
is the
hashing function used, and RSA
is the encryption algorithm used.
Trusting a Certificate
There are a battery of tests that can be run on a certificate to determine if it should be trusted. These tests may vary from application to application, but most will use a similar subset, which we’ll discuss below.
Certificate Authorities
While certificates are an important tool for identifying who exactly you’re
talking to, they come with a tremendous problem: why should you trust the
certificate? Anyone can make a certificate claiming to be
www.google.com, so how can you tell which is the real
one? This is where a certificate authority (or CA) comes into play. A CA will
fall into one of two categories: root or intermediate. Which category the CA is
classified as is determined by the certificate it uses for issuing. If the
certificate was created on its own (or in otherwords, not issued by any
organization), it is called a root certificate. Since nobody issues a root
certificate, the issuer field will always match the subject. We can see this in
the root.pem
certificate:
Issuer: C = US, ST = Texas, L = Austin, O = Acme CA, OU = Security, CN = Acme Root CA
...
Subject: C = US, ST = Texas, L = Austin, O = Acme CA, OU = Security, CN = Acme Root CA
On the other hand, an intermediate CA means that it requested (and received) its issuing certificate from another CA (which might be an intermediate CA itself). It is common practice for a root CA to issue only a few intermediate CA certificates, then not be used again. This minimalizes impact in the event one of the intermediate CA’s becomes compromised.
The Certificate Chain
As we just discussed, certificates are usually issued by CA’s upon request.
The cert.pem
certificate used in this article came from a CA, which we can see
in the issuer field:
Issuer: C = US, ST = Texas, L = Austin, O = Acme CA, OU = Security, CN = Acme Intermediate CA
With this information, we can then determine the certificate that issued it, based on two facts:
- The subject field of the issuing certificate with match the issuer field of
cert.pem
exactly. - The public key of the issuing certificate will be able to successfully
verify against the digital signature of
cert.pem
Remember how I said it is important that the issuer and subject fields don’t change? This is why. They are an important part in determining the issuing certificate.
With this information in hand, we can then discover that int.pem
is the
issuer:
Subject: C = US, ST = Texas, L = Austin, O = Acme CA, OU = Security, CN = Acme Intermediate CA
However, the issuer field of int.pem
does not match the subject, so we know
that int.pem
itself came from another CA:
Issuer: C = US, ST = Texas, L = Austin, O = Acme CA, OU = Security, CN = Acme Root CA
Repeating the process, we can see that root.pem
issued int.pem
:
Subject: C = US, ST = Texas, L = Austin, O = Acme CA, OU = Security, CN = Acme Root CA
Since the issuer field of root.pem
is the same as the subject, we know that it
is a root certificate, and no CA issued it:
Issuer: C = US, ST = Texas, L = Austin, O = Acme CA, OU = Security, CN = Acme Root CA
Certificates that are linked in this manner are referred to as a certificate
chain. So in this case, our certificate chain is root.pem
-> int.pem
->
cert.pem
.
The Trust Store
While the certificate chain is important for knowing which certificates you can
trust to identify entities, it doesn’t completely solve the problem. It has now
shifted to knowing which root certificates you can trust. Operating systems and
applications solve this by keeping what is called a trust store. There are
several other names for it as well, such as system roots or the keychain. It is
a collection of every root certificate trusted by the system. Several well
known and popular authorities have their root certificates in most trust stores
by default, such as Let’s Encrypt, DigiCert, and GoDaddy. So, if root.pem
(Acme Root CA) was in the trust store, that means root.pem
would then be
trusted. Any certificate signed by root.pem
is then trusted as well, which
includes int.pem
. Now, all certificates signed by int.pem
are trusted as
well, so assuming no other validation tests fail, cert.pem
will be trusted.
So, to recap, your system or application will (usually) only trust root
certificates found in the trust store. Any certificate chains that stem from one
of these roots are implicitly trusted as well (again, assuming they don’t fail
any of the other tests).
Proper Attributes and Path Length
Every link in a certificate chain, except the last one, must be a CA
certificate, which is what allows it to issue further certificates. The primary
extension a CA certificate must contain is the Basic Constraints
OID, with a
value of CA:TRUE
. If Basic Constraints
is set to CA:FALSE
, or is not
present at all, then it is not a CA certificate. Each of the certificates in our
chain has the Basic Constraints
extension with one of those two values:
root.pem
X509v3 Basic Constraints: critical
CA:TRUE
int.pem
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
cert.pem
X509v3 Basic Constraints:
CA:FALSE
You may have noticed that int.pem
not only has a value of CA:TRUE
, but also
pathlen:0
. This is a limitation set by the issuing certificate (root.pem
)
that dictates how far it can extend the certificate chain with further issuing
certificates. Since it has a path length (pathlen
) of 0, it cannot issue any
further issuing certificates, just regular certificates like cert.pem
. If it
had a path length of 1, it could issue one further CA certificate, but that CA
certificate would not be able to create further CA certificates.
Certificate Expiration
This test should be fairly self explanatory. If a certificate is used before its start date, or after its finish date, it should not be trusted. If any link of a certificate chain is expired, the entire chain should not be trusted.
The Subject Alternative Name (SAN)
I’ve stated more than once that the actual contents of the subject (and issuer)
DN, which is true with modern certificates. However, the common name piece used
to be a way for certificates, such as cert.pem
, to identify entities. There
were several issues with this however. Namely, almost anything can go into the
common name, including characters that aren’t valid in a domain name. The
subject alternative name (or SAN) extension was then implemented, to allow a
certificate to identify a list of 1 or resources. Each resource is in the format
of type:name
. For example, we can see that cert.pem
only covers the DNS name
acme.naughtysysadmins.com
:
X509v3 Subject Alternative Name:
DNS:acme.naughtysysadmins.com
Google solidified this with the release of version 58 of the Chrome browser. At
that point, they stopped accepting any identifying information from the common
name field, and now require all names a certificate covers to be in the SAN
list. If a certificate (such as cert.pem
) is used by a name it doesn’t cover
(such as acme2.naughtysysadmins.com
), then the certificate will not be
trusted. Most modern systems that validate certificates have adopted this
practice.
Certificate Revocation
There may be times when a certificate needs to be invalidated early, before its expiration date. There could be a number of reasons for this, such as the entity using the certificate being decommisioned, or a CA becoming compromised. Due to this, several methods for revoking (and thus invalidating) a certificate have been standardized. Since these methods all largely vary in implementation and usage, we won’t be discussing them in depth here. However it is good to know that these methods exist. Some popular revocation standards are:
- Certificate Revocation Lists (CRL) - A list that can be downloaded from a CA listing all of the certificates it has revoked.
- Online Certificate Status Protocol (OCSP) - A way to allow the system
validating a certificate to do an
HTTP
lookup to see the status of the certificate. - Certificate Transparency - A collection of public databases that can be queried to see the status of any given certificate.
A CA is not required to opt into any particular revocation method, however most popular CA’s will implement as many as they can to support the largest number of systems possible.
Alternative Tests
This article does not cover every test a system might run on a certificate chain to validate it. However, these are some of the most important ones. Some systems may reject any certificate that doesn’t come from a specific CA. Others may test that the public key of the certificate is a particular strength. Further tests like these can vary from system to system, so it can be a good idea to confirm exactly what tests a given system (such as your browser) will run on a certificate chain.
Certificate Formats
As stated earlier, certificates and LDAP
come from the same family of
standards, collectively known as X.500
. Certificates are specified by the
standard referred to as X.509
. The X.509
standard is a comprehensive guide
that dictates how a certificate is structured and encoded. In a nutshell,
X.509
describes the layout of a certificate as an DER
-encoded ASN.1
data
structure. While I’m sure that was as clear as mud, it should make more sense as
we discuss each of these terms.
Abstract Syntax Notation One (ASN.1)
According to Wikipedia, ASN.1
is an “interface description language”. Simply
put, it is used to describe how a data structure looks. For example, if we
wanted to describe a data structure that held someone’s name and age, it might
look like this:
Person ::= SEQUENCE {
age INTEGER,
name IA5String
}
ASN.1
has many rules, and can be quite complex. Luckily, it isn’t something
you should normally need to deal with, as it is an incredibly low-level piece of
the puzzle. It is still good to know however, that ASN.1
is the language
specification used to describe the certificate (in the form of a data
structure). If you would still like to take a look at ASN.1
, you can copy the
following certificate (int.pem
) and plug it into
this site, then just hit decode
:
-----BEGIN CERTIFICATE-----
MIIFvjCCA6agAwIBAgICEAAwDQYJKoZIhvcNAQELBQAwajELMAkGA1UEBhMCVVMx
DjAMBgNVBAgMBVRleGFzMQ8wDQYDVQQHDAZBdXN0aW4xEDAOBgNVBAoMB0FjbWUg
Q0ExETAPBgNVBAsMCFNlY3VyaXR5MRUwEwYDVQQDDAxBY21lIFJvb3QgQ0EwHhcN
MTkwNDEzMDI1NDM2WhcNMjkwNDEwMDI1NDM2WjByMQswCQYDVQQGEwJVUzEOMAwG
A1UECAwFVGV4YXMxDzANBgNVBAcMBkF1c3RpbjEQMA4GA1UECgwHQWNtZSBDQTER
MA8GA1UECwwIU2VjdXJpdHkxHTAbBgNVBAMMFEFjbWUgSW50ZXJtZWRpYXRlIENB
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxfeCQy7LrZ/z+BjsDTZx
iFxMbdmw5ZPHiqwsXuruxLm/WssvgfMPC6TVQfhnlxNCQKDZc/5eFXrYjEtZT54Z
7ZVhoPMH7Ed7m1QC0JxqIAZBkMo3XgT0ThQBXdNFCPe9GYVmvoipyAZexXjXR9L/
nxMCs5xKR0UIECqTyJNglN1ovzC/kzbR1A2ocGkFVQSK8VhHaYBdKWKDF0gY+MxI
96aJvDI/geb2hAsZoYfmbGE+h0kdbZ1gpJcyvzyjLVrzCYIguEGExiMzgPOTDoFE
Q1lXU4aBO1B0zbEQIJ7LS1WApdQnMTFn2/YyuEd8GZTB/FdfRMVwjK2DRAGodryP
B90f+5aOjGXj4Wu0sRjX4JzdQvk4Th+mWogNZHktjKKs+pyrI+siSvulKT08qG9C
ahL35fS9chvbSBBNz36OLGuFMoRd3OBLXvF5cNmYlffGv/Ha6mGrnQIpcUr2/Avv
8eiwd9/xQwVAv0tieaYKovzGwy4uw7xoQXQWq4DrFWckrz0UIlgvkzukYli0fJUR
sI5NMyFVsylzuqAXBXZUrLFJKxNdfqOse/8NbY/LvnmNQI9NwwV9Vq9bYSx5Ox2Q
IRIK8kBU98R7ZDb7RRhJrgQbY8yRlgleu9w0n4IHm44b19dofgJAHTG/WqC/o5wH
QmlKd9+QnNcUNFCW/1xeZ/cCAwEAAaNmMGQwHQYDVR0OBBYEFBSCOgl2/+p+eXDH
A2w455pdzYRXMB8GA1UdIwQYMBaAFPAKQ5nG361QxGf5fW1il23dI4NJMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC
AQCw9OnNuasqnOMSXqx3aDTr7gcBdj9IZCxh93ZmXab8OO+Jngre0F29P8+PGPmv
8aRgZ9pq/k/5FMPiEdxCGU7krZgrFqpPNppOROPT301SuddmDWLia4gvNPt/Wg63
4Li5vH58hPsgSe9XDbD5f6SA8Nr2okw61/sFhNYOAiV6d0KrhsCT4HOHBRyBw2Ui
GTxeVTIgW3jeWzhS6+GBnuVZTLeW0s5i+CtgrVwXNyNHr/RARABMiArTJv+eMBUZ
VICakZnwOfwx5Uc+xxX6jowiU3zu3gyfPN2Vh50BOgsMOC/zDM20VLTHjpwsZ34p
vDCjAETXJj5QiaBAFykbSH55U6aKAMA68QK8cB7KkbAVOHn2FDKGaag6KQEczqbU
PV24pdpkEe90h40Bpwjb8x5Z8L8KF2+tuPhUeCqTB0DpnWKrt1I4Xc/r8bAmFDaD
H9eHX2w8wVu2qgxJ5GRJoEraWZMRQH4kj4KQJHZ/hSZTDi0YUrc+QxdpCRZVUQ0C
DI3Kk2By40e0QHYeqIx4FlLb/6at3Re0iZxYhXVIu+r9vsIx6UGndOXMMbqyMQOB
4UhRGiDQGYkV7Qa5lj9HKgCSx3p4B/L4a10bZlJpVkTcs2ZK8J2cgXU7fN31KIf/
esAlZVk/qssH3H5deI3zl21EAaoSTilQYz0VMtY6CtZBgQ==
-----END CERTIFICATE-----
Basic Encoding Rules (BER)
Specified by the X.690
standard, it describes how an ASN.1
data structure
should be encoded in a binary format, so that it can be easily transferred and
distributed. So, while ASN.1
describes how a data structure is laid out, BER
describes how it is actually stored as a file. You will not usually, if ever,
see a certificate encoded using BER
.
Distinguished Encoding Rules (DER)
DER
, which is also specified by X.690
, is a subset of BER
, and is actually
used for encoding certificates. The main difference between the two is that
BER
allows for multiple ways to encode an object or data structure, whereas
DER
only allows for one way (to mitigate ambiguity).
Privacy-Enhanced Mail (PEM)
As DER
is a binary encoding, it is not easy to work with on a high level.
PEM
, specified by RFC 7468, greatly simplifies this. When a DER
-formatted
certificate is translated to PEM
, the contents are all re-encoded as BASE64,
with 64 characters maximum per line. This allows you to store the certificate in
a human-readable format. A PEM
-encoded certificate will also begin with:
-----BEGIN CERTIFICATE-----
and end with:
-----END CERTIFICATE-----
In case you didn’t notice, the certificate from the ASN.1
section is actually
PEM
-encoded.
X.509
Now that it is more clear what ASN.1
and DER
are, hopefully the overview of
X.509
makes more sense: X.509
describes the layout of a certificate as an
DER
-encoded ASN.1
data structure. This is basically a fancy of way saying
X.509
describes what goes into a certificate (as an ASN.1
data structure),
and how that certificate is stored (as a binary encoding, according to DER
).
Besides the actual attributes you might find in a certificate (which we’ll get
to later on), there isn’t much else to X.509
that you really need to know for
the remainder of this article.
Dealing with Actual Certificate Files
PEM
and DER
-encoded files are the two most common formats you’ll work with
when you have a certificate. The filename could use a variety of extensions,
such as:
.cer
(which is not related to Canonical Encoding Rules in this context).der
.pem
.crt
.cert
Regardless of how it is named, there is a high probability the file is in one of
those two formats. More often than not, PEM
is usually used, for a variety of
reasons: it is easier to open and read in an editor, it is easier to copy and
paste (for example, into a form on a website to inspect the certificate), and
finally doesn’t trigger any warnings about trying to download a binary-encoded
file. However, as DER
is the actual underlying encoding for the certificate,
it isn’t impossible to find a file formatted this way.