tls ssl cert - ghdrako/doc_snipets GitHub Wiki

TLS is a generic protocol for wrapping individual TCP/IP connections. Where solutions like IPSec can tunnel and encrypt all traffic between two IP addresses, TLS encrypts only a single connection.

TLS certificate information is organized as per X.509, the International Telecommunications Union’s (ITU) standard for digital certificates. X.509 is used in many applications that demand precise formatting of data. It defines how certificates will be arranged, which features are used, how they’re validated and revoked, and more.

X.509, in turn, is built on Abstract Syntax Notation One (ASN.1), another ITU standard. ASN.1 is a method for defining cross-platform data structures and providing information in a globally recognized manner.

ASN.1 is built by arranging objects into a tree. Each branch and leaf on the tree is identified by a numerical Object Identifier, or OID. X.509 shares a tree with protocols like SNMP, but is on a different branch. New objects are slowly but constantly added to TLS certificates. Each CA has its own chunk of the object tree. Your software might not have all of the OIDs in a certificate.

CAs can also use private OIDs, such as those from 1.3.9900 to 1.3.9999

X.509 also pillages the X.500 directory standard. X.500 defines one- or two-letter labels for different types of information, such as OU =, O =, and CN =.

  • OU represents Organizational Unit, a division of that entity
  • CN gives the Common Name, which was historically a hostname in TLS. Using CN to store hostnames has been deprecated since 2000,as CN cannot support hostnames longer than 63 characters. The replacement for hostnames in CN is called Server Alternative Names (SAN). Many CAs transparently copy hostnames from the CN to SANs. The Common Name might be a uid, email address, first and last name, or some combination thereof. It could even be a serial number, identifying a device.

Each directory item has an OID. If you poke around, you’ll see that the omnipresent CN is 2.5.4.3.

  • SAN Server Alternative Names (SAN) are non-critical extension

Validation Levels:

  • domain validated (DV) certificate means that the CA verified that the requesting entity owns and controls the domain the certificate is for. All free ACME and most inexpensive certs are DV. Need to demonstrate that I own and control the host that the name points at, or that I can add entries to the DNS.
  • organization validated (OV) certificate includes everything in a DV certificate, but also checks that the requesting organization exists and is at the address claimed. Most commercial CAs offer OV certificates.
  • extended validated (EV) certificate digs into the entity requesting the certificate. It verifies the organization’s business registration and jurisdiction. This sort of certificate includes everything you need to track down the organization. These certificates can run thousands of dollars.

Each certificate type contains the information validated. A DV certificate contains only the domain name. An OV certificate includes basic organizational information, while an EV certificate gives you all sorts of data.

Certificate Components

A certificate contains two primary pieces:

  • the information about the entity being certified, and
  • a digital signature of that information.

The certificate also includes a public key. This organization information and the public key is gathered together into an X.509-formatted file called a certificate signing requestor CSR. You submit the certificate signing request to your Certificate Authority. You hide the private key like the treasure it is.

The CA verifies the information in the certificate signing request. Once the CA is satisfied of the request’s legitimacy it attaches any delegated permissions and digitally signs the whole thing. That’s the certificate. Certificates have validity dates, or at least an expiration date. Clients may reject expired certificates.

Using a certificate requires the certificate file returned from the CA, plus the private key created when you made the certificate signing request.

Encoding certificates

While certificates all use the X.509 format, a system can encode and store those certificates in many ways. An encoding is a method of arranging data. It has nothing to do with encryption, ciphers, or secret codes and everything to do with serializing objects for transmission and storage.

Distinguished Encoding Rules (DER)

The Distinguished Encoding Rules (DER) is one of the oldest methods of encoding X.509 certificates. DER is a subset of the Basic Encoding Rules for ASN.1, or BER. DER gives a unique and unambiguous encoding of any ASN.1 object. Every system that supports DER will interpret this data in precisely the same way. DER is a binary format. Everything is encoded with a tag, a length, and then the data. You can’t copy and paste a DER certificate or send it in the body of an email. To treat a certificate as text, you must convert it to PEM.

Privacy-Enhanced Mail (PEM)

The IETF created a standard for sending encrypted email, Privacy- Enhanced Mail (PEM), back in 1993. PGP defeated PEM in the Email Cryptography Swordfight, but PEM encoding proved suitable for keys and certificates and survived. PEM is mostly base64-encoded DER, plus headers and footers to make it more human-friendly. they start with a line of dashes and the words BEGIN CERTIFICATE or BEGIN RSA PRIVATE KEY and end with line by a line declaring END CERTIFICATE or KEY.

PKCS #12

PKCS #12, however, defines how to store multiple related encryption files in a single archive file. This archive can be encrypted and digitally signed. It’s most commonly used to store a certificate chain and its private key. Each file goes in a separate container in the archive, called a SafeBag. You might use PKCS #12 to email a private key and its certificate to a colleague in your organization. So long as you use a good password and send that password out of band11, it’s fairly safe. Java uses PKCS #12 heavily. It’s the default key storage format as of Java 8, which has added several features that make it not entirely compatible with other PKCS software.

The PFX file format was a precursor to PKCS #12

  • SNI - Server Name Indication - client indicates which hostname it is attempting to connect to at the start of the handshaking process.1(https://en.wikipedia.org/wiki/Server_Name_Indication#cite_note-rfc3546-1) This allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites (or any other service over TLS) to be served by the same IP address without requiring all those sites to use the same certificate. Gatway inspect the SNI headers and present specific certificate and route the traffic to the specific backend. When an HTTPS connection is created, the client first identifies which service it’s trying to reach using the ClientHello part of the TLS handshake. Istio’s gateway (Envoy,specifically) implements SNI on TLS, which is how it can present the correct cert and route to the correct service.

  • SAN - subjectAltName field Subject Alternative Name - allows various values to be associated with a security certificate using a subjectAltName field.1(https://en.wikipedia.org/wiki/Subject_Alternative_Name#cite_note-1) These values are called Subject Alternative Names (SANs). SAN is an extension to the X.509 specification that allows users to specify additional host names for a single SSL certificate. Each of these names will be considered protected by the SSL certificate.

Originally, SSL certificates only allowed the designation of a single host name in the certificate subject called Common Name (CN) but now this has undergone change and a certificate is first verified for SAN and if no SAN is defined it falls back to CN.

It is still a practice to define both CN and SAN when requesting a certificate. An important point is that CN and SAN are not complimentary and any CN defined should be a subset of SAN list.

CN max char 64. SAN much more.

  • CN commonName field Common Name - represents the server name protected by the SSL certificate. The certificate is valid only if the request hostname matches the certificate common name. The common name can only contain up to one entry: either a wildcard or non-wildcard name. SAN was introduced to solve this limitation. CN has max size 64 char

It is still a practice to define both CN and SAN when requesting a certificate. An important point is that CN and SAN are not complimentary and any CN defined should be a subset of SAN list.

[req]
req_extensions = v3_req

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = server1.example.com
DNS.2 = mail.example.com
DNS.3 = www.example.com
DNS.4 = www.sub.example.com
DNS.5 = mx.example.com
DNS.6 = support.example.com

There are several types of SSL Certificates:

  • SSL Certificates by Validation Level
    • Domain Validated SSL Certificates - validates the domain is registered and someone with admin rights is aware of and approves the certificate request.
    • Organization Validated SSL Certificates (OV certificate) - validates the domain ownership, plus organization information included in the certificate such as name, city, state and country.
    • Extended Validation SSL Certificates (EV certificate) - validates domain ownership and organization information, plus the legal existence of the organization. It also validates that the organization is aware of the SSL certificate request and approves it.
  • SSL Certificates by Secured Domains
    • Single-name SSL Certificates - protects a single subdomain (hostname)
    • Wildcard SSL Certificates - protect an unlimited number of subdomains for a single domain ex *.example.com
    • Multi-Domain SSL Certificates(SAN certificate) - protect different domains with a single certificate, using the SAN extension

There are two types of certificate authorities (CAs):

  • root CAs and
  • intermediate CAs. For an SSL certificate to be trusted, that certificate must have been issued by a CA that’s included in the trusted store of the device that’s connecting.

The list of SSL certificates, from the root certificate to the end-user certificate, represents the SSL certificate chain.

Format certyfikatu X.509 DN Distingis Name CN OU O L ST C -

CA Bundle

CA Bundle is the file that contains root and intermediate certificates. Together with your server certificate (issued specifically for your domain), these files complete the SSL chain of trust. The chain is required to improve the compatibility of the certificates with web browsers, email clients, and mobile devices.

If you’ve received your root and intermediate certs as separate files, you should combine them into a single one to create the CA Bundle file.

  • certyfikat główny - CARoot.crt
  • certyfikat pośredni 1 - Intermediate1.crt
  • certyfikat pośredni 2 - Intermediate2.crt
  • certyfikat pośredni 3 - Intermediate3.crt
  • certyfikat wystawiony dla domeny/witryny - twoja_domena.crt

Polaczenie plikow w bundle:

  • Linux i systemy oparte na UNIX --
cat EssentialSSLCA_2.crt ComodoUTNSGCCA.crt UTNAddTrustSGCCA.crt AddTrustExternalCARoot.crt > yourDomain.ca-bundle
  • Windows lub DOS
copy EssentialSSLCA_2.crt + ComodoUTNSGCCA.crt + UTNAddTrustSGCCA.crt + AddTrustExternalCARoot.crt yourDomain.ca-bundle

Most software expects to find certificates in /etc/ssl/certs. Each Unix also has their own way to manage these certificates. Maybe it’s certctl, or add-trusted-cert, or update-ca-certificates, or a tangle of OpenSSL commands. If you need to add or remove certificates from the OpenSSL trust store, check your operating system documentation for the correct way to do so.

Cipher Suites

In TLS terms, a cipher suite is a specific combination of a particular symmetric, checksum, and public key algorithms, plus other details needed so that each party can encrypt and decrypt messages comprehensible to the other party. It’s often referred to as a cipher.

Example:

  • TLS_RSA_WITH_AES_256_CBC_SHA ( short version AES256-SHA)
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_CCM_8_SHA256
  • TLS_CHACHA20_POLY1305_SHA256

Syntax:

  • TLS 1.2: Protocol_Kx_Au_WITH_Enc_MAC

  • TLS 1.3: Protocol_Enc_MAC

  • Kx is the key exchange method, one of ECDHE, DHE, ECDH, DH,or RSA.

  • Au is the authentication method, either ECDSA or RSA. If both key exchange and authentication use the same method, such as RSA, it only appears once.

  • Enc gives the symmetric encryption plus the mode of operation, one of CBC, CCM, CCM_8, or GCM.

  • The MAC, or Message Authentication Code, is one of SHA, SHA256, or SHA384