Overview
Why: Encryption (hiding data sent on the wire) and Identification (ensure the computer you are speaking to is what it claims to be).
Introduction
In TLS (an updated replacement for SSL), a server is required to present a certificate as part of the initial connection setup. A client connecting to that server will perform the certification path validation algorithm:
- The subject of the certificate matches the hostname (i.e. domain name) to which the client is trying to connect;
- The certificate is signed by a trusted certificate authority.
A TLS server may be configured with a self-signed certificate. When that is the case, clients will generally be unable to verify the certificate, and will terminate the connection unless certificate checking is disabled.
Certificate
The certificate, contains the public key, plus additional information such as issuer, what the certificate is supposed to be used for, and other types of metadata.
Typically, a certificate is itself signed by a certificate authority (CA) using CA’s private key. This verifies the authenticity of the certificate.
Certificate types
- trust anchors (root CA certs)
- intermediate CA certs
- end-entity certs
cert chain
Certificate format
.pem, .crt, .cer, .pfx (includes both the public and private key)
.pem can contain multiple certificates
openssl
How to use Certificate Authority (CA) to issue the SSL certificate or generate self-signed certificate
Python
http/https
verify with a custom certificate (that client trusts)
r = requests.post(url, data=data, verify=’/path/to/public_key.pem’)
socket
cafile, capath, cadata represent optional CA certificates to trust for certificate verification, as in SSLContext.load_verify_locations(). If all three are None, this function can choose to trust the system’s default CA certificates instead.
