Skip to content

Latest commit

 

History

History
116 lines (106 loc) · 7.24 KB

pki_with_openssl.md

File metadata and controls

116 lines (106 loc) · 7.24 KB

Key and Certificate Management

  • Key algorithm
    • for web server keys everyone uses RSA
    • For SSH, DSA and RSA are widely used
  • Key size
    • Today, 2,048-bit RSA keys are considered secure
    • Aim also to use 2,048 bits for DSA keys and at least 256 bits for ECDSA
  • Passphrase
    • strongly recommended
    • Protected keys can be safely stored, transported, and backed up
    • but either too inconvenient or has unacceptable availability implications
    • using protected keys in production does not actually increase the security much
      • because, once activated, private keys are kept unprotected in program memory; an attacker who can get to the server can get the keys
    • Thus, passphrases should be viewed only as a mechanism for protecting private keys when they are not installed on production systems.
  • To generate an RSA key, use the genrsa command
    • it’s best to stay away from the other algorithms(DES, 3DES, and SEED)
    • Private keys are stored in the so-called PEM format

Creating CSRs

  • if you want a field to be empty, you must enter a single dot (.) on the line, rather than just hit Return. If you do the latter, OpenSSL will populate the corresponding CSR field with the default value.
    • For some fields there will be a default value, If you enter '.', the field will be left blank.
    • Having a challenge password does not increase the security of the CSR in any way. Further, this field should not be confused with the key passphrase, which is a separate feature.
  • Unless you’re using some form of public key pinning and wish to continue using the existing key, it’s best practice to generate a new key every time you apply for a new certificate. Key generation is quick and inexpensive and reduces your exposure.

Creating Certificates Valid for Multiple Hostnames

  • There are two mechanisms for supporting multiple hostnames in a certificate. The first is to list all desired hostnames using an X.509 extension called Subject Alternative Name (SAN). The second is to use wildcards. You can also use a combination of the two approaches when it’s more convenient. In practice, for most sites, you can specify a bare domain name and a wildcard to cover all the subdomains (e.g., feistyduck.com and *.feistyduck.com).

Examining Certificates

  • the address of the CA’s Online Certificate Status Protocol (OCSP) responder, which can be used to check for certificate revocation in real time.

When checking certificates validation that are made by private CA

  • Clear browser history to delete old site certificates
  • Add(or remove and add) the CA bundle to make the validation succeed

Extended Key Usage

  • This extensions consists of a list of usages indicating purposes for which the certificate public key can be used.

AIA(Authority Information Access) extention

  • AIA extension allows SSL/TLS clients (mostly web browsers) to go get the missing intermediate certificates, not presented by the server.
  • Servers that do not send the entire chain are in breach of the SSL/TLS standard.
  • Certificates are validated in order as a chain as follow.
    • Site certificate -> Intermediate CA certificates -> Root CA certificate
  • Also contains OCSP URI
  • https://www.tbs-certificates.co.uk/FAQ/en/453.html

CRL, OCSP and OCSP stapling

Browsers

  • Soft-fail
    • "The browser will try to do a revocation check, but if the response doesn't come back, or doesn't come back in a short period of time, the browser will simply forget about it. Even is worse is that Chrome doesn't even do revocation checks, at all."
  • Chrome and Firefox both have their own mechanisms that push sets of revocation list contributed by CAs
  • Google Chrome
  • Firefox
    • Uses 'OneCRL', Soft-fail
    • Firefox does not work with OCSP stapling emitting "SEC_ERROR_OCSP_BAD_SIGNATURE"
    • With just OCSP responder, it works fine
    • https://wiki.mozilla.org/CA:ImprovingRevocation
      • OCSP responders are not yet reliable enough for us to do hard fail
      • Websites that implement OCSP Must-Staple will get Hard Fail Revocation.
      • As of Firefox 24, the user-interface for importing CRLs via Firefox has been removed. Auto-importing/updating of CRLs through Firefox has also been removed. NSS still supports CRLs, but Firefox is moving away from checking CRLs, and moving towards using a revocation list push mechanism.
  • Both work fine with private PKI if you deploy the certificates properly.
    • Root CA certificates for the operating systems and browsers
    • Site certificates, private keys and intermediate CA certificates for the HTTP servers
    • It is not mandatory to prepare CRL and OCSP responder to keep your service up and running as of now due to 'soft-fail'.

Automatic Certificate Management Environment (ACME)

Reference

Other solutions