CS469/569 - Linux and Unix Administration and Networking

The purpose of certificates is to establish a trust relationship with a second party via the use of public/private key signing with identity verification through certificate authorities. The key point is to verify that the person or organization on the remote end (such as your bank) is who they claim to be, then finally establishing a secure encrypted communications channel with them. It is important to note that is not merely to establish secure comms, as there are other protocols that can do that, but is intended to verify identity, i.e. it makes no difference if we can security communicate with a hacker, we want to securely communicate with our bank.

Terms:

Format of a certificate:

The following information should be present in a certificate as defined by the X.509 protocol.

Certificate
    Version         - Version number for this certificate
    Serial Number   - Unique number for this cert
    Algorithm ID    - The signature algorithm used
    Issuer          - CA authority information.
    Validity        - Dates for which this cert is valid
        Not Before
        Not After
    Subject         - The subject/domain for this certificate
    Subject Public Key Info
        Public Key Algorithm
        Subject Public Key
    Issuer Unique Identifier (optional)
    Subject Unique Identifier (optional)
    Extensions (optional)
        ...
Certificate Signature Algorithm
Certificate Signature

An example of the CS servers certificate information, as obtained via the
command: openssl x509 -text -in certificate.crt

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0f:de:de:23:43:74:b0:1a:c2:4d:b2:5f:dd:50:5b:93
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
        Validity
            Not Before: Jul  1 00:00:00 2018 GMT
            Not After : Jul 15 12:00:00 2020 GMT
        Subject: C = US, ST = Indiana, L = Terre Haute, O = Indiana State University, CN = *.indstate.edu
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:e2:5a:9f:69:fb:be:f0:42:42:0c:c6:88:f8:a6:
                    e4:b9:a0:3b:68:f7:1f:e9:06:46:9d:a4:ce:20:c8:
                    a9:68:39:e8:41:73:93:03:c4:d3:1f:de:50:b5:48:
                    3a:f5:de:d3:b2:22:64:e5:b9:ba:56:a2:7d:09:45:
                    eb:f0:8a:1b:0c:9c:81:d1:9d:6f:3d:3a:54:19:ef:
                    95:f1:0e:cd:00:12:1a:13:a5:2e:73:43:f7:a0:86:
                    a5:da:e3:06:37:35:d2:c7:1f:b1:a0:d3:e8:1a:f1:
                    61:f4:aa:b9:21:2f:9c:77:a9:99:3a:0d:9d:48:d6:
                    d5:0d:92:67:79:65:69:ec:db:5d:10:1f:e2:ec:0e:
                    4d:e5:e4:85:6e:dd:d7:fb:ad:ad:6a:ef:fa:8f:6e:
                    e8:ce:a9:9e:1b:0f:a9:62:ff:a0:32:1e:0a:c7:70:
                    97:b3:e9:66:1e:e2:28:2b:87:77:52:6e:1c:5b:3a:
                    42:d6:3e:18:2d:8a:11:d3:30:72:61:8c:26:e9:fd:
                    5f:11:7c:78:9c:3d:0f:12:a6:5a:2c:bb:62:92:af:
                    ca:eb:f2:4d:fb:68:ed:c8:86:c1:22:68:ee:d5:7e:
                    23:58:0e:b3:e9:00:cd:b2:12:3e:cb:20:4c:0b:8d:
                    e6:06:42:c3:a5:bb:89:b2:71:a8:af:73:d2:71:14:
                    d4:4d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:51:68:FF:90:AF:02:07:75:3C:CC:D9:65:64:62:A2:12:B8:59:72:3B

            X509v3 Subject Key Identifier: 
                53:42:6A:41:C6:EE:8B:7C:09:DF:91:61:4F:7E:E2:5B:F3:6B:78:CB
            X509v3 Subject Alternative Name: 
                DNS:*.indstate.edu, DNS:indstate.edu, DNS:cs.indstate.edu, DNS:mathcs.indstate.edu, DNS:marilyn.indstate.edu
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl3.digicert.com/sha2-ha-server-g6.crl

                Full Name:
                  URI:http://crl4.digicert.com/sha2-ha-server-g6.crl

            X509v3 Certificate Policies: 
                Policy: 2.16.840.1.114412.1.1
                  CPS: https://www.digicert.com/CPS
                Policy: 2.23.140.1.2.2

            Authority Information Access: 
                OCSP - URI:http://ocsp.digicert.com
                CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt

            X509v3 Basic Constraints: critical
                CA:FALSE
            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : EE:4B:BD:B7:75:CE:60:BA:E1:42:69:1F:AB:E1:9E:66:
                                A3:0F:7E:5F:B0:72:D8:83:00:C4:7B:89:7A:A8:FD:CB
                    Timestamp : Jul  1 02:45:23.272 2018 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:4D:99:3E:0C:57:5D:12:2F:75:31:AE:D8:
                                25:18:76:21:51:A1:07:96:3F:6F:AB:C5:0E:F2:AC:27:
                                16:CF:8F:A1:02:21:00:AA:84:A6:DB:D3:3E:91:1A:EF:
                                5D:EF:4A:46:CD:DE:E7:B6:74:11:79:DE:70:69:94:4D:
                                4D:11:0B:3A:9A:2D:68
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 87:75:BF:E7:59:7C:F8:8C:43:99:5F:BD:F3:6E:FF:56:
                                8D:47:56:36:FF:4A:B5:60:C1:B4:EA:FF:5E:A0:83:0F
                    Timestamp : Jul  1 02:45:23.397 2018 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:21:00:FE:0E:D7:66:49:B4:3A:2F:3D:CB:0F:
                                DA:25:8A:4E:59:6E:8D:5D:30:A7:10:AB:94:AB:86:C2:
                                96:37:8D:D0:39:02:20:4D:4D:0D:BB:CB:6A:C8:CB:66:
                                09:98:84:67:4E:3A:F2:99:97:B0:C1:4B:48:5A:D1:BC:
                                0E:93:7D:7B:06:86:E4
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : BB:D9:DF:BC:1F:8A:71:B5:93:94:23:97:AA:92:7B:47:
                                38:57:95:0A:AB:52:E8:1A:90:96:64:36:8E:1E:D1:85
                    Timestamp : Jul  1 02:45:23.195 2018 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:14:3D:E6:68:0F:F2:2B:AB:C1:39:49:73:
                                2E:CD:8D:F4:29:3A:77:8E:11:63:3C:98:49:81:17:98:
                                03:9B:5A:61:02:20:36:0E:7B:EF:25:24:83:10:72:EC:
                                9B:EC:6E:9A:C2:4D:1F:27:23:13:95:87:01:A9:D9:BE:
                                C3:CA:75:6F:1F:F3

Certificate creation, signing and management:

Common command sets:

Creating a Certificate Authority:

To create a Certificate Authority for purposes of certificate signing we make a directory for all the files and configurations for our CS, then setup a openssl.cnf configuration file:

The req_distinguished_name field defines the name of the Issuer. The Issuer and Subject identity fields are:

Under policy_match the fields define what identity fields of the Subject must either "match" the Issuers identity, are required (supplied) or may be optionally supplied (optional).

The v3_req extensions have to be re-coded for each certificate, so ought to probably be left undefined for any CA you initially create.

Once you have a properly setup CA directory (and all the required sub-directories as define in the openssl.cnf files CA_default section, you can begin creating the keys and signing certificates via the following steps:

Steps to then create the CA:

1) Create a 2048 bit RSA key:

This generates the CA's private key, against which all certificates are signed. The key should be stored where the openssl.cnf file says it is located at. This key should be kept private, non-readable and never shared. If the key is released to the wider world, all certificates signed against it are now invalid. An attacker would also then be able to sign invalid certificates as you.

2) Creating a certificate authority:

> openssl req -new -x509 -days 3650 -key root-ca.key -out root-ca.crt -config openssl.cnf

This creates the root certificate authority certificate root-ca.crt, using the root key. You'll need to change the paths to the correct file locations.

3) Creating a certificate request:

Create certificate request:
> openssl req -new -sha256 -key domain.key -out domain.csr

The certificate signing request is then signed against the private key. The domain.csr is then sent to the CA to be signed.

4) Signing a certificate request:

The CA then signs the CSR (using the information in the config file,) the output in newcert.pem is a PEM formatted certificate which is then sent back to the subject.

Quick self-signed certs:

> openssl req -new -newkey rsa:2048 -x509 -nodes -keyout server.key -out server.crt -days 9999

This will create a private key (server.key) and a self-signed certificate (server.crt). Often useful for quickly setting up some certificates for testing purposes.

Convert between pkcs12 and pem formats:

Converts from the Windows standard pkcs12 format to Linux's pem format standard.

Converts from the Linux pem (includes both private key and cert) format to Windows standard pkcs12 format.

Test server/client:

> openssl s_server -port port -cert public-key -key private key -www

Creates a "web server" on port using a certificate and private key. Useful for testing purposes.

Connects to hostname:port, displaying any certificate information from the host.

The SSL/TLS handshake:

Encryption:

Public Key exchange is used to securely share a secret key: A seed to a stream cipher or Pseudo-Random Number Generator (PRNG), or a key to a block cipher. The use of signed certificates is used to facilitate trust in the exchange of these keys -- that we're trading keys with the entity we want and not some man in the middle. The certificate contains the public key of the person or organization to which we want to communicate, which we can use to begin encryption with them by encrypting the above mentioned seed.

In public/private key exchange, the public key unlocks an item encrypted by the private key and vice-versa. By way of an over-simplified example, imagine that a public key was the number 20, and the private key was the multiplicative inverse, i.e. 1/20 A number, our seed, is enciphered by the subject using the public key. Suppose the seed was 33. The message sent to the holder of the private key is then 33*20 or 660. Some imagination is required to imagine that it is impossible to deduce the seed number from the public key, which is normally the case. The owner of the private key can however recover the seed value by multiplying the 660 by 1/20 to get the original 33. You can maybe imagine how it can also work in the other direction.

Stream ciphers (RC4, et.al.)

RC4 is an example of a stream cipher which is really a cryptographically secure Pseudo Random Number Generator (PRNG). A PRNG will always produce the same sequence of seemingly random numbers when seeded with the same seed number. Both ends of a connection seed their PRNGs with the same seed number.

Once the shared seed is used to initialize the PRNG, the data to be shared it XOR'ed (Exclusive OR'ed) with the stream of random bits from the PRNG on the sending side.

The receiver XOR's the received data with its PRNG data, resulting in the original un-encrypted data.

Where D_i is Data byte i and E_i is the Encrypted data for data byte i. Using the same random value from the PRNG reverse the encryption.