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 example cert.pem, we can see that it can only be used to identify acme.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.