Applied Cryptography and PKI: Encryption, Signatures and Key Management

1. Introduction

Applied cryptography and PKI is the discipline behind almost everything we take for granted on a connected system: the encryption of an HTTPS session, the signature of a document, mutual authentication between services and the chain of trust that makes your browser trust a certificate issued by a public CA. Yet textbook theory collides with day-to-day reality: keys that have not been rotated in years, expired certificates taking production services down, and signatures validated poorly because nobody checked the hash algorithm. In this article I cover applied cryptography and PKI from the practitioner’s point of view: the cryptographic concepts you must master, X.509 certificate anatomy, a complete OpenSSL lab to build your own CA, step-by-step digital signatures and key lifecycle management best practices. Everything is reproducible on an Ubuntu or Debian machine. Applied cryptography and PKI is mastered in the terminal, not in the books, and this text is meant to be opened next to a machine.

2. Cryptographic fundamentals you must master

Before touching a single OpenSSL command, fix the three building blocks of applied cryptography and PKI: symmetric cryptography, asymmetric cryptography and hash functions. Symmetric (AES-256-GCM, ChaCha20) is fast and encrypts data at rest and in transit, but requires sharing the same key through a secure channel — exactly the chicken-and-egg problem. Asymmetric (RSA, ECDSA, Ed25519) solves key exchange with a key pair: the public key is distributed freely and the private key never leaves its source device. Hash functions (SHA-256, SHA-384) provide integrity and, combined with a private key, produce digital signatures.

Asymmetric cryptography is slow; that is why real protocols use it only to negotiate a symmetric session key and encrypt the rest of the conversation with it. That hybrid design is what you will see in TLS 1.3, OpenVPN and most full-disk encryption. In applied cryptography and PKI this point matters to avoid design mistakes: encrypting every connection with RSA would be unworkable, and relying on symmetric-only cryptography makes key management impossible at scale. Understanding that division of labor lets you read any design built on applied cryptography and PKI.

My minimum baseline for 2026: AES-256-GCM for data encryption, SHA-256 or stronger for integrity, and elliptic curves (P-256 or Ed25519) for signatures and key exchange, leaving RSA only for legacy interoperability. The OWASP cheat sheet on cryptographic storage is an excellent executive summary to fix these minimums before writing code.

3. Digital certificates and the X.509 infrastructure

A digital certificate is the document with which a well-designed applied cryptography and PKI deployment binds an identity to a public key. The standard structure is defined in RFC 5280: version, serial number, signature algorithm, issuer, validity period, subject, public key and extensions such as Subject Alternative Name, key usage and CA constraints. Inspect your own installation with openssl x509 -in ca.crt -noout -text and you will see every field: each one participates in a trust decision.

3.1 CA hierarchy and chains of trust

The root CA issues intermediate CAs, and those issue server or user certificates; the client only trusts the root and validates the chain by verifying each signature up to it. That hierarchy is why a compromised root CA forces regeneration of the whole ecosystem, while a compromised intermediate is revoked with far less impact. In corporate applied cryptography and PKI, separating root from intermediates is one of the first design decisions, and it should be made before issuing the first certificate.

Another practical distinction: TLS server certificates (serverAuth/clientAuth), code-signing certificates, S/MIME email signing and document signing certificates. The Extended Key Usage field limits exactly what each certificate may do, and respecting it is part of good craftsmanship. One detail that keeps appearing in audits: certificates issued with overly broad usages end up signing documents they should not, or acting as TLS servers without oversight. That usage control is a common blind spot in corporate applied cryptography and PKI.

4. Lab: building a PKI with OpenSSL

Nothing fixes applied cryptography and PKI better than building your own CA on an isolated machine. The following lab creates the directory structure, generates an offline root CA and issues a signed server certificate. Start with the CA configuration file:

[ ca ]
default_ca = jaymon_ca

[ jaymon_ca ]
dir               = ./ca
database          = $dir/index.txt
new_certs_dir     = $dir/newcerts
certificate       = $dir/ca.crt
private_key       = $dir/private/ca.key
serial            = $dir/serial
default_md        = sha256
policy            = policy_loose
default_days      = 825

[ policy_loose ]
countryName             = optional
stateOrProvinceName     = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied

Fig. 1 – openssl.cnf: minimal CA configuration for OpenSSL.

With the configuration in place, we generate the materials and the root. The CA key must be encrypted with AES-256 and, ideally, kept on a disconnected device:

mkdir -p ~/pki/ca/{newcerts,crl,private}
cd ~/pki/ca
touch index.txt
echo 1000 > serial
openssl genrsa -aes256 -out private/ca.key 4096
openssl req -x509 -new -key private/ca.key -sha256 -days 3650 \
  -out ca.crt -config openssl.cnf \
  -subj "/C=ES/ST=Madrid/O=Jaymon Security/CN=Jaymon Security CA Root"

Fig. 2 – Generating the root key and self-signing the CA certificate.

The genrsa command asks twice for the passphrase that protects the key; if you lose it, there is no recovery. The root is self-signed by its own private key and is the only self-signed certificate in the lab. Keep this machine offline and powered down: applied cryptography and PKI reserves the root operation for a handful of occasions per year.

4.1 Issuing a server certificate

With the CA operational, issuance happens in two steps: the subject generates its key pair and certificate signing request (CSR), then the CA validates and signs. The server’s private key must never be copied to the CA machine:

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr \
  -subj "/C=ES/O=Jaymon Security/CN=servidor.jaymonsecurity.es"
openssl ca -config openssl.cnf -in server.csr -out server.crt \
  -days 825 -notext -extensions server_cert
openssl x509 -in server.crt -noout -text | head -30

Fig. 3 – Certificate signing request and server certificate issuance.

Notice the flow: the CA never sees the server’s private key, and the server never sees the CA’s key or passphrase. That separation of duties is the trust foundation of all applied cryptography and PKI. The output of the last command must show the subject, the issuer and the validity period; the full chain is validated with openssl verify -CAfile ca.crt server.crt.

If your goal is production, replace this homegrown CA with materials from a certified provider (Let’s Encrypt for public TLS or your corporate KMS for internal use) and use this lab to understand what you are doing. The official OpenSSL documentation will help you get the most out of every parameter. The lab already shows why the profession separates issuer and subject: that is the hallmark of mature applied cryptography and PKI.

5. Digital signatures: creating and validating in practice

A signature does not encrypt the content: it proves the document arrived intact and that a specific private key endorsed it. The flow inverts confidentiality —you encrypt a digest with the private key and anyone decrypts it with the public one— and a large share of applied cryptography and PKI rests on that foundation. The following example signs and verifies a document with the lab server key:

echo "Service contract - Jaymon Security - 2026" > contract.txt
openssl dgst -sha256 -sign server.key -out contract.sig contract.txt
# Extract the public key and verify the signature
openssl pkey -in server.key -pubout -out server_pub.pem
openssl dgst -sha256 -verify server_pub.pem \
  -signature contract.sig contract.txt

Fig. 4 – Digital signature of a document and verification with the public key.

The verification result must read Verified OK. Change a single letter in the contract and repeat: the signature will fail, proving that document integrity is protected by the hash. In enterprise environments, document signatures usually rely on formats such as PDF-ASIC or CAdES with added timestamps; in all of them the underlying cryptographic engine is exactly what you just ran. Mastering this sign-verify loop is the rite of passage for anyone working with applied cryptography and PKI.

5.1 Validation errors you will see in production

When validation fails, the cause is usually one of three: the certificate is expired, the subject name does not match the domain (CN/SAN mismatch), or the root/intermediate is missing from the trust store. The first diagnostic question on any system should be “who signs this certificate, and do I trust that CA?”. Understanding that validation path is more useful than memorizing parameters: applied cryptography and PKI is mastered by learning to read a certificate chain, not by running commands from memory.

6. Key lifecycle management

Management is the least glamorous and most important part of applied cryptography and PKI. A key without inventory, rotation or revocation loses all its value. Without a management routine, even the soundest applied cryptography and PKI design collapses at the first incident. The table below summarizes typical materials and recommended sizes for 2026:

Material	Recommended algorithm	Size/key	Recommended rotation	Typical use
Symmetric key	AES-256-GCM	256 bits	Annual	Data and session encryption
Server signature	ECDSA P-256 / Ed25519	256 / 256 bits	24-36 months	TLS, mutual authentication
Document signature	RSA-3072 / ECDSA	3072 / 256 bits	18-24 months	Corporate signatures
CA root	RSA-4096 or ECDSA	4096 / 384 bits	5-10 years (manual)	Root of the trust chains

Table 1 – Algorithms, sizes and recommended rotation for cryptographic materials.

Revocation deserves its own paragraph because it is where daily operations fail the most. If a private key leaks, the certificate must be revoked and its status published in a CRL or served via OCSP; clients that honor these lists will reject the material. Publishing status on time is the most neglected operation in operational applied cryptography and PKI. In practice, the time between incident detection and revocation publication is the metric auditors reward the most. Sign your CRLs daily and monitor OCSP traffic to detect clients that never check certificate status.

On storage, raise the bar: HSMs and KMS manage keys without ever exposing them to application software, and a TPM module can custody server keys in hardware. Corporate applied cryptography and PKI ends the moment a key is copied to a USB stick or pasted into an internal chat; from there the whole system degrades. The NIST key management program (NIST SP 800-57) is the canonical reference if you need to dive deeper into validity periods and algorithm usage. Hardware custody is the logical closing piece of a serious applied cryptography and PKI.

7. Conclusion

Applied cryptography and PKI is not a lab topic: it is the nervous system of trust in your infrastructure. With clear fundamentals, your own OpenSSL CA lab, hands-on signing and verification practice, and rigorous key lifecycle management, your team stops depending on scattered tutorials and makes encryption decisions with technical judgment. Applied cryptography and PKI rewards those who work it with method.

Actionable summary: encrypt with AES-256-GCM, sign with ECDSA or Ed25519, keep root and intermediates separate, rotate on a calendar, revoke and publish status within minutes, and custody keys in hardware whenever the budget allows. The next time a certificate expires on a Friday at 5:00 PM, your team will know exactly what to do, how to audit the material and where to document it.

Need help with Applied cryptography and PKI?

At Jaymon Security, we help organizations protect their systems. From security audits to SIEM/SOC implementation, our expert team designs custom solutions.