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.
Certificate Authority (CA)
Certificate Signing Request (CSR)
X.509
SSL (Secure Sockets Layer)
TLS (Transport Layer Security (supersedes SSL))
.pem (Privacy Enhanced Mail?)
.pfx (PKCS #12) Public-Key Cryto Standards
Certificate Revocation list (CRL):
Public key
Private key
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
> openssl command [options]
> openssl
Example:
> openssl x509 -text -in *certificate-file* Display information from a certificate file, use the x509 command set.
> openssl x509 -text -in *certificate-file*
Command What it is for x509 X.509 Certificate Data Management. ca Certificate Authority (CA) Management. req PKCS#10 X.509 Certificate Signing Request (CSR) Management. s_client Implements a generic SSL/TLS client which can establish a transparent connection to a remote server speaking SSL/TLS. s_server Implements a generic SSL/TLS server which accepts connections from remote clients speaking SSL/TLS. It's intended for testing and provides both an own command line oriented protocol for testing SSL functions and a simple HTTP response facility to emulate an SSL/TLS-aware webserver.
x509
ca
req
s_client
s_server
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:
openssl.cnf
mkdir CA cd CA cp /etc/ssl/openssl.cnf .
Then we make the changes necessary to the configuration, defining our CA:
Changes to openssl.cnf:
[ CA_default ] dir = /path/to/CA # Where everything is kept (change /path/to) certificate = $dir/<CAname>.crt # The CA certificate private_key = $dir/<CAname>.key # The private key default_days = 999 # how long to certify for default_md = sha1 # which md to use. [ req ] default_bits = 2048 # Required number of bits in the keys [ req_distinguished_name ] countryName_default = <country> stateOrProvinceName_default = <state> localityName_default = <city> 0.organizationName_default = <company name> organizationalUnitName_default = <Unit in company name> commonName_default = <domain> subjectAltName = Alt names subjectAltName_default = DNS:<domain>.com,DNS:mail.<domain>.com,DNS:mail.<otherdomain>.com,... emailAddress_default = <email address> [ v3_req ] # Extensions to add to a certificate request subjectAltName = DNS:<domain>.com,DNS:mail.<domain>.com,DNS:mail.<otherdomain>.com,... [ policy_match ] countryName = match stateOrProvinceName = optional organizationName = supplied organizationalUnitName = optional commonName = supplied emailAddress = optional
The req_distinguished_name field defines the name of the Issuer. The Issuer and Subject identity fields are:
req_distinguished_name
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).
policy_match
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.
v3_req
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:
CA_default
> openssl genrsa -out root-ca.key 2048
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.
> 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.
root-ca.crt
Create a private key: > openssl genrsa -out domain.key 2048
> openssl genrsa -out domain.key 2048
This is done by the subject, not the CA. This is the subjects private key.
Create certificate request: > openssl req -new -sha256 -key domain.key -out domain.csr
> 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.
> openssl ca -in domain.csr -out newcert.pem -config ./openssl.cnf
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.
newcert.pem
> 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.
server.key
server.crt
> openssl pkcs12 -in input.pfx -out output.pem
Converts from the Windows standard pkcs12 format to Linux's pem format standard.
> openssl pkcs12 -export -in input.pem -out output.pfx
Converts from the Linux pem (includes both private key and cert) format to Windows standard pkcs12 format.
> openssl s_server -port port -cert public-key -key private key -www
> openssl s_server -port
-cert
-key
-www
Creates a "web server" on port using a certificate and private key. Useful for testing purposes.
> openssl s_client -connect hostname:443
Connects to hostname:port, displaying any certificate information from the host.
Client connects to server and sends a list of supported cipher suites (ciphers and hash functions)
Server picks a cipher and hash it also supports and tells client.
Server sends it's digital certificate, which includes its server name, Certificate Authority (CA) and public key.
Client may verify the certificate with the CA.
Client generates session keys by encrypting random numbers using the servers public key and sends the encrypted keys to the server.
Server can then decrypt the sessions keys using it's private key.
The session key(s) are used to initialize a hash or stream cipher to the same state on both ends, which are then used to encrypt the traffic.
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.
20
1/20
33
33*20
660
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.
XOR operation: 0 ⊕ 0 = 0 0 ⊕ 1 = 1 1 ⊕ 0 = 1 1 ⊕ 1 = 0 Di ⊕ PRNGi = Ei Ei ⊕ PRNGi = Di
Where Di is Data byte i and Ei is the Encrypted data for data byte i. Using the same random value from the PRNG reverse the encryption.
i
Good distribution of random data (should not favor certain numbers or bits)
Large period between repeating data. Where: PRNGi = PRNGi+k for all 0 <= i < k. k should be large, for all input seeds.
Good PRNGs tend to be more computationally expensive (slower.)
Permute blocks of data (usually of a fixed size) based on a reverable function, permuted by a specific key.
Sender takes a block of data, applies the permutation function to the data, then send to the reciver.
Reciver uses the inverse of the permutation function to decode the orginal data. The operation of the permutations is contingent upon the key being used.