Certificates and PKI (Public-Key Infrastructure)

Basics

In order to have a secure connection to a web site via HTTPS, it is necessary to both encrypt the traffic and authenticate the site. The encryption happens via TLS, but TLS depends on the server having a public key which is authenticated via a certificate. The certificate in turn binds that key to the server's identity. The server uses the private key associated with that public key to complete the TLS handshake, thus proving that it is the correct owner of that identity. Without the certificate, your browser could just be forming a secure connection to an attacker.

These certificates are issued by certificate authorities (CAs), who are responsible for validating the server's identity, issuing the certificate, and revoking it if something goes wrong (e.g., the server's key is compromised). ...

...

The way things work in practice is that the client has a list of CAs that it trusts to issue certificates ...

... the goal of certificates and PKI is to bind names to public keys.

...

Authentication, in general, is the process of confirming the truth of some claim.

...

A signature can be verified using a public key but can only be generated with a corresponding private key. Thus, a recipient that only has a public key can verify signatures, but can't generate them. ...

...

There are two things you can do with a key pair:

• You can encrypt some data with the public key. The only way to decrypt that data is with the corresponding private key.
  
  
• You can sign some data with the private key. Anyone who knows the corresponding public key can verify the signature, proving which private key produced it.
  

...

... public key cryptography lets one computer (or bit of code) prove to another that it knows something without sharing that knowledge directly. ...

...

What if you don't already know my public key? That's what certificates are for.

Certificates are fundamentally really simple. A certificate is a data structure that contains a public key and a name. The data structure is then signed. The signature binds the public key to the name. The entity that signs a certificate is called the issuer (or certificate authority) and the entity named in the certificate is called the subject.

...

... if you've never met some computer before, but you trust some certificate authority, you can use a certificate for authentication: verify that the certificate is valid (check signature, etc), look at public key, "look at private key" [communicate with owner of private key ?] across network, read name.

...

Web PKI ... defines what a "name" is and where it goes in a certificate, what signature algorithms can be used, how a relying party determines the issuer of a certificate, how a certificate's validity period (issue and expiry dates) is specified, how revocation and certificate path validation works, the process that CAs use to determine whether someone owns a domain, and a whole lot more.

Web PKI is important because Web PKI certificates work by default with browsers and pretty much everything else that uses TLS.

Internal PKI is PKI you run yourself, for your own stuff: production infrastructure like services, containers, and VMs; enterprise IT applications; corporate endpoints like laptops and phones; and any other code or device you want to identify. It allows you to authenticate and establish cryptographic channels so your stuff can run anywhere and securely communicate, even across the public internet.

Why run your own internal PKI if Web PKI already exists? The simple answer is that Web PKI wasn't designed to support internal use cases. ...

Further, with Web PKI you have little or no control over important details like certificate lifetime, revocation mechanisms, renewal processes, key types, and algorithms ...

Finally, the CA/Browser Forum Baseline Requirements actually prohibit Web PKI CAs from binding internal IPs ...

...

... "how does the relying party know the issuer's public key?""

The answer is simple, if not satisfying: relying parties are pre-configured with a list of trusted root certificates (or trust anchors) in a trust store. The manner in which this pre-configuration occurs is an important aspect of any PKI. ...

So where do trust stores come from? For Web PKI the most important relying parties are browsers [and operating systems] ...

... if you run your own internal PKI you should maintain a separate trust store for internal stuff. ...

...

... the subject alternative name (SAN) X.509 extension to bind a name in a certificate.

There are four sorts of SANs in common use, all of which bind names that are broadly used and understood: domain names (DNS), email addresses, IP addresses, and URIs. ...

The only difference is the types of programs they're used for (PGP usually for email or encrypted messages, SSH usually for securing remote connection to computers, SSL usually for running a website or anything else done over SSL), but besides that they're the same keys just wrapped in a different container.

...

PGP is mostly used for text messages between people, like email. You typically send the decoding key out to people, and a lot of people might have it. Or you might make it public so everyone has it, and it doesn't really encrypt anything, but proves you are really you, since you are able to 'sign' things.

SSH is generally to talk one machine to one other machine. If you want your laptop to connect to one linux server you make one SSH for key. Multiple computers can use the same key and it works, but the idea is one to one. You download it and one computer can talk to another computer.

SSL is good for automatic connections. Anyone can go up to an encrypted website and get a key to talk to it, so no one else can read what you are doing with it, but it'll give one to anyone.

...

There's another difference not mentioned yet: in SSH, the keys are used on their own, but in SSL (really TLS these days) there's also a certificate, which is the public key with some information about the subject, bound together by being signed with the private key.

...

These are not different kinds of encryption, they are different protocols that give other people the information they need to understand how they can decrypt or verify your message. They may allow for an array of different options for exact cryptographic algorithm, which is important so that we can upgrade to more secure ones over time, or fix bugs. The connection protocols, TLS and SSH, also have some kind of negotiation built in, so that the machines can understand each other and perform key exchange.

PGP (1991): Pretty Good Privacy, designed for digital signatures and encryption for individual messages, such as emails. You might be using this somewhere without knowing about it, e.g. it might be used to sign your emails.

SSL (1994)/TLS (1999): Secure Socket Layer/Transport Layer Security, protocol for encrypted connections, also allowing for proof of identity with digital certificates. Best for public-facing web servers, to the point that all of your web traffic goes over TLS now, browsers will warn you if it is not.

SSH (1995): Secure SHell, secure machine-to-machine command-line protocol, which includes logging into a user account. Similar, in principal, to SSL, but higher-level and more advanced and allows all machines to interface with each other at the command-line level. You probably won't use SSH unless you are a developer, the most common use is SFTP (which is basically just running the FTP protocol inside an SSH connection.)

Web Certificates

Trusted certificate stores

ls /etc/ipsec.d/cacerts
ls /usr/share/ca-certificates
ls /usr/share/ca-certificates/mozilla
ls /etc/pki
ls -l /usr/local/share/ca-certificates
ls -l ~/.mozilla/firefox/*.default-release/cert*
locate .pem   # finds files everywhere
sudo ls -l /etc/ssl/private   # key files
openssl version -d      # usually says "/etc/ssl"

# Symlinks to cert files in other dirs.
# Updated by running "update-ca-certificates".
ls /etc/ssl/certs

# To get the "subject" of every CA certificate in /etc/ssl/certs/ca-certificates.crt:
awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{close(cmd)};{print | cmd}' </etc/ssl/certs/ca-certificates.crt

# List all certs in system and display issuer and expiration date:
locate .pem | grep "\.pem$" | xargs -I{} openssl x509 -issuer -enddate -noout -in {}

# System CAs ?
trust list --filter=ca-anchors
ls /etc/pki/ca-trust/source/whitelist/

# Java certificates:
keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts

# Firefox certificates:
cd $HOME/.mozilla/firefox/PROFILEDIR     # where cert9.db file is
certutil -L -d .             # list all certs
certutil -K -d .             # list nicknames of certs
certutil -O -d . -n NICKNAME # show info about a cert
# https://firefox-source-docs.mozilla.org/security/nss/legacy/tools/certutil/index.html

# NSS certificate store, maybe openSUSE only, used by Firefox and Evolution and Network Manager ?
ls $HOME/.local/var/pki/nssdb/
# https://doc.opensuse.org/documentation/leap/security/single-html/book-security/index.html#cha-certstore

# man openssl-x509
# check for certs expired or due to expire in next month (30*24*60*60 == 2592000 seconds)
for f in `ls /etc/ssl/certs/*.pem`
do
	openssl x509 -checkend 2592000 -noout -in "$f" >/dev/null
  if [ $? -ne 0 ]
  then
	  openssl x509 -issuer -enddate -noout -in "$f"
  fi
done

# See certs used to make a connection:
openssl s_client -showcerts -connect DESTDOMAIN:443

# Snap version of sqlitebrowser fails, don't use it.
# https://sqlitebrowser.org/
sudo apt install sqlitebrowser
sqlitebrowser --help

sqlitebrowser --read-only --table nssPublic ~/.mozilla/firefox/*.default-release/cert9.db
# Personal certs are listed among the others.
# The interesting data is in a blob in column a11, I think.
# But I think this is a cache; not all certs are listed.

# man openssl-pkcs12
locate .p12 .pfx
openssl pkcs12 -in CERTNAME.p12 -out TMP.pem -nodes -clcerts
openssl x509 -issuer -enddate -checkend 2592000 -noout -in TMP.pem
rm TMP.pem
openssl pkcs12 -info -nodes -in CERTNAME.p12

# Check a certificate in a crt file:
openssl x509 -in CERTNAME.crt -text -noout

# Check a certificate in a der file:
openssl x509 -in CERTNAME.der -inform der -text

openssl verify CERTNAME.*     # any file type

# A .pfx file has both public and private PKCS12 keys, can contain multiple certs, can be password-protected.
# A .p12 file has both public and private PKCS12 keys, can contain multiple certs, can be password-protected.
# .pfx is predecessor of .p12
# A .key file has both public and private PKCS8 keys, in either DER binary or PEM ASCII format.
# A .cer file has only public key, in either DER binary or PEM ASCII format.
# A .crt file has only public key, in either DER binary or PEM ASCII format.
# A .der file has only public key, in DER binary format.
# A .pem file has only public key, in Base-64 and with a header and footer added.
# A .ca-bundle file has only public key, what format ?
# A .pvk file has only private key.

SSH

Certificate Formats

• RSA / SSH public-private key-pair.
  
  Usually generated by a client, which authenticates to a server some other way and then sends the public key to that server, for future use in authentication.
  Never expire.
  File id_rsa.pub is the public key and file id_rsa is the private key.
  Can these files hold multiple key-pairs, or only one pair ?
  ~/.ssh directory.
  
  
• Identity certificate.
  
  X.509, usually generated and signed by a trusted authority.
  Has an expiration date.
  Wikipedia's "X.509"
  Personal cert file types .pem .p12 .pfx.
  Authority cert file types .cer .cert .crt. Also .der ?
  Supratim Samanta's "Deep Dive into SSL certificates"
  
  
• PGP public-private key-pair.
  
  Never expire.
  ~/.gnupg directory.
  
  
  

Miscellaneous

Historically there have been four algorithms in a cipher suite:

• Key Exchange.
• Digital Signature.
• Message Authentication.
• Hashing Algorithm.