33. Cryptography Basics

33.5 Digital Signatures, Certificates, PKI and TLS

By Ravindra Bagale · Last updated: 27 September 2026

Digital signature: hash the message, then encrypt the hash with your private key. Anyone verifies with your public key. If the message changes, the hash no longer matches. This gives integrity, authentication and non-repudiation.

openssl dgst -sha256 -sign private.pem -out msg.sig msg.txt
openssl dgst -sha256 -verify public.pem -signature msg.sig msg.txt     # Verified OK
echo "changed" >> msg.txt
openssl dgst -sha256 -verify public.pem -signature msg.sig msg.txt     # Verification failure

Certificates and PKI. How do you know a public key really belongs to reels.example.in? A Certificate Authority (CA) such as Let's Encrypt (Chapter 11) signs a certificate saying "this public key belongs to this domain". Browsers trust a list of root CAs; the chain goes root CA, intermediate CA, your certificate. This system is PKI (Public Key Infrastructure).

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
openssl req -x509 -newkey rsa:2048 -nodes -keyout lab.key -out lab.crt -days 30 -subj "/CN=lab.local"   # self-signed, lab only

How TLS (HTTPS) uses everything, in short:

1. The browser connects and the server sends its certificate.
2. The browser checks the CA signature, the domain name and the expiry date.
3. Both sides use ECDHE to agree on a fresh shared secret (this gives forward secrecy).
4. All data then flows encrypted with AES-GCM or ChaCha20, with integrity checks.

Use TLS 1.2 or 1.3 only; disable SSLv3, TLS 1.0 and 1.1. Tools such as sslscan, testssl.sh and nmap --script ssl-enum-ciphers check a server's configuration.