Most of the following is taken from the OpenSSL cookbook
OpenSSL does not come with any trusted root certificates (also known as a trust store). DL Mozilla's truststore [here](https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins... /certdata.txt). Note: It's in a custom format so needs conversion so use this tool.
- generate a strong private key
- create a Certificate Signing Request (CSR) and send it to a CA
- install the CA-provided certificate in your web server
Usually contain only the most basic certificate data. By comparison, certificates issued by public CAs contain a number of additional fields (via the X.509 extension mechanism).
The Basic Constraints extension is used to mark certificates as belonging to a CA, giving them the ability to sign other certificates. Non-CA certificates will either have this extension omitted or will have the value of CA set to FALSE . This extension is critical, which means that all software-consuming certificates must understand its meaning.
X509v3 Basic Constraints: critical
CA:FALSE
The Key Usage (KU) and Extended Key Usage (EKU) extensions restrict what a certificate can be used for. If these extensions are present, then only the listed uses are allowed. If the extensions are not present, there are no use restrictions.
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
The CRL Distribution Points extension lists the addresses where the CA’s Certificate Revocation List (CRL) information can be found. This information is important in cases in which certificates need to be revoked. CRLs are CA-signed lists of revoked certificates, published at regular time intervals (e.g., seven days).
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.starfieldtech.com/sfs3-20.crl
The Certificate Policies extension is used to indicate the policy under which the certificate was issued. For example, this is where extended validation (EV) indicators can be found (as in the example that follows). The indicators are in the form of unique object identifiers (OIDs), and they are unique to the issuing CA. In addition, this extension often contains one or more Certificate Policy Statement (CPS) points, which are usually web pages or PDF documents.
X509v3 Certificate Policies:
Policy: 2.16.840.1.114414.1.7.23.3
CPS: http://certificates.starfieldtech.com/repository/
The Authority Information Access (AIA) extension usually contains two important pieces of information. First, it lists the address of the CA’s Online Certificate Status Protocol (OCSP) responder, which can be used to check for certificate revocation in real time. The extension may also contain a link to where the issuer’s certificate (the next certificate in the chain) can be found. These days, server certificates are rarely signed directly by trusted root certificates, which means that users must include one or more intermediate certificates in their configuration. Mistakes are easy to make and will invalidate the certificates. Some clients (e.g. Internet Explorer) will use the information provided in this extension to fix an incomplete certificate chain, but many clients won’t.
Authority Information Access:
OCSP - URI:http://ocsp.starfieldtech.com/
CA Issuers - URI:http://certificates.starfieldtech.com/repository/sf_intermediate.crt
The Subject Key Identifier and Authority Key Identifier extensions establish unique subject and authority key identifiers, respectively. The value specified in the Authority Key Identifier extension of a certificate must match the value specified in the Subject Key Identifier extension in the issuing certificate. This information is very useful during the certification path-building process, in which a client is trying to find all possible paths from a leaf (server) certificate to a trusted root. Certification authorities will often use one private key with more than one certificate, and this field allows software to reliably identify which certificate can be matched to which key. In the real world, many certificate chains supplied by servers are invalid, but that fact often goes unnoticed because browsers are able to find alternative trust paths.
X509v3 Subject Key Identifier:
4A:AB:1C:C3:D3:4E:F7:5B:2B:59:71:AA:20:63:D6:C9:40:FB:14:F1
X509v3 Authority Key Identifier:
keyid:49:4B:52:27:D1:1B:BC:F2:A1:21:6A:62:7B:51:42:7A:8A:D7:D5:56
The Subject Alternative Name (SAN) extension is used to list all the hostnames for which the certificate is valid. This extension used to be optional; if it isn’t present, clients fall back to using the information provided in the Common Name (CN), which is part of the Subject field. If the extension is present, then the content of the CN field is ignored during validation.
X509v3 Subject Alternative Name:
DNS:www.feistyduck.com, DNS:feistyduck.com
ssh-rsa AAAAB3N....NMqKM= this_is_a_comment That part of an ssh key is just a comment. You can change it to anything you want at any time. It doesn't even need to be the same on different servers. You can remove it as well. It is only there to help you or someone else figure out what to delete when you have many keys in an authorized_keys file and you need to revoke or change one of them.