September 12, 2026
12 min read
By Kokil Thapa | Last reviewed: September 2026
Every HTTPS site, signed PDF, and API token you trust depends on Public Key Infrastructure (PKI) Explained in plain terms: a system of keys, certificates, and authorities that binds identities to public keys. If you deploy Laravel apps, run law-firm portals, or manage Linux servers in Nepal, PKI is already in your stack—even when nobody labels it that way. This guide walks through how PKI works, where it breaks in production, and what you should configure on real systems. For broader security context, see our Linux system administration services and related DevOps writing on kokil.com.np.
Quick answer: Public Key Infrastructure (PKI) Explained simply: trusted Certificate Authorities issue X.509 certificates that bind a public key to an identity; clients verify the chain, check revocation, and use asymmetric cryptography so private keys never travel over the network.
What is Public Key Infrastructure (PKI) and how does it work?
PKI is the framework that makes asymmetric cryptography usable at scale. You generate a key pair: a private key you guard and a public key you share. A Certificate Authority (CA) signs a certificate stating that a given public key belongs to a domain, organisation, or device. Browsers and servers trust CAs whose root certificates sit in their trust stores.
The core promise is identity binding. Without PKI, anyone could present any public key and claim to be your bank, API, or client portal. With PKI, a verifier checks the signature chain, validity dates, key usage flags, and often revocation status before trusting the connection.
Three roles appear in almost every deployment. The subject holds the private key and presents the certificate. The issuer (CA) signs that certificate. The relying party validates the chain and decides whether to trust the subject. On production servers I maintain, that relying party is often Nginx, Apache, or a load balancer terminating TLS before PHP-FPM handles the request.
PKI also covers more than HTTPS. Code signing, email S/MIME, document signing on legal portals, VPN client auth, and mutual TLS (mTLS) for service-to-service APIs all reuse the same X.509 machinery with different Extended Key Usage (EKU) flags.
Key objects you should recognise
- Private key: Stays on disk, in a vault, or in an HSM. Never commit it to Git.
- Certificate Signing Request (CSR): Contains the public key plus subject details; sent to a CA for signing.
- X.509 certificate: Binds identity to public key; includes validity window, SANs, and extensions.
- Trust store: Collection of root and intermediate CA certificates the client already trusts.
- CRL / OCSP: Mechanisms to check whether a certificate was revoked before expiry.
For a deeper companion read, our post on PKI and certificate management basics covers operational checklists. The canonical standard for certificate profiles is RFC 5280, which defines X.509 v3 fields browsers and CAs implement today.
How does the TLS certificate chain establish trust during HTTPS?
When a browser opens https://example.com, the server sends its leaf certificate plus any intermediate certificates. The client builds a chain from leaf to a trusted root. Each link must be signed by the parent. The leaf hostname must match a Subject Alternative Name (SAN). Dates must fall inside the validity window.
If any step fails, you get the familiar browser warning—or in API clients, a silent TLS handshake failure that surfaces as cURL error 60 or Guzzle connection errors. I have seen Laravel apps work locally over HTTP and fail in staging purely because the staging cert used an internal CA the server trust store did not know.
Inspect a live certificate chain from the command line
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName
echo | openssl s_client -showcerts -connect example.com:443 -servername example.com 2>/dev/null \
| awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{print}' > chain.pemThe first command shows who issued the cert and which SANs are valid. The second dumps the chain for offline inspection. On Ubuntu servers where I run Certbot, the live files usually land under /etc/letsencrypt/live/domain/ with symlinks to fullchain.pem and privkey.pem.
Apache and Nginx need the full chain, not just the leaf. Serving an incomplete chain causes Android clients and some API libraries to fail while desktop Chrome still works—a frustrating partial outage. Our domain registration and hosting service includes TLS setup because this chain detail catches small teams off guard.
What is the difference between public CAs, private PKI, and internal CAs?
Not every certificate comes from a public CA like Let's Encrypt or DigiCert. Enterprises often run a private PKI for internal APIs, VPN users, or staging environments. The cryptography is identical; only the trust anchor differs.
| Model | Who trusts it | Typical use | Cost / ops |
|---|---|---|---|
| Public CA (DV/OV/EV) | Global browser and OS trust stores | Public websites, customer APIs | Free–USD hundreds/yr; automated via ACME |
| Private / internal CA | Only systems where you install the root | Microservices mTLS, VPN, dev/stage | Low direct cost; you own rotation and audit |
| Cloud-managed PKI | Your cloud IAM plus configured trust | AWS ACM, Azure Key Vault certs | Per-cert or per-request pricing; less HSM ops |
For public law-firm and eCommerce sites I have shipped—such as Notary Nepal and Court Marriage In Nepal—public DV certificates from Let's Encrypt are the default. They are free, auto-renewable, and trusted everywhere. Private PKI enters the picture when two backend services must authenticate each other without exposing endpoints to the public internet.
HashiCorp Vault's PKI secrets engine is a common middle ground for teams that want dynamic short-lived certs without operating a full Microsoft AD CS deployment. We covered that pattern in HashiCorp Vault PKI secrets engine.
How do you issue and renew TLS certificates on a production Linux server?
Most small and mid-size deployments on Ubuntu use Certbot with the webroot or nginx plugin. The ACME protocol proves domain control; the CA signs a short-lived certificate—typically 90 days for Let's Encrypt—which forces automated renewal.
- Point DNS A/AAAA records to your server and open ports 80 and 443.
- Install Certbot and request a certificate for all SANs you need.
- Configure the web server to reference
fullchain.pemandprivkey.pem. - Add a cron or systemd timer for
certbot renewplus a reload hook. - Monitor expiry externally so a failed renewal does not surprise you.
sudo certbot certonly --nginx -d example.com -d www.example.com
sudo certbot renew --dry-run
sudo install -d /etc/letsencrypt/renewal-hooks/deploy
printf '%s\n' '#!/bin/sh' 'systemctl reload nginx' > /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.shCertbot documentation at letsencrypt.org/docs remains the best reference for ACME edge cases. After renewal, reload PHP-FPM or Nginx so workers pick up the new cert without a full reboot.
Apache SSLVirtualHost example
<VirtualHost *:443>
ServerName example.com
DocumentRoot /var/www/example/public
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder on
</VirtualHost>Disable legacy TLS versions. PCI and modern browser baselines expect TLS 1.2 minimum; TLS 1.3 is preferred where supported. On shared EC2 boxes hosting multiple Laravel sites, I isolate each vhost cert and verify renewal hooks reload only the affected service.
Document portals such as Mijar Law Associates rely on this chain for client trust in the browser padlock. The same PKI primitives also protect uploaded files in transit when clients use HTTPS-only cookies and HSTS headers.
How do you use PKI for API authentication beyond HTTPS?
Server TLS proves the API identity to the client. Mutual TLS (mTLS) also proves the client identity to the server. Each side presents a certificate; the server verifies the client cert against a trusted CA or allow-list. This pattern fits machine-to-machine calls better than long-lived API keys embedded in config files.
Laravel 12 and 13 applications can terminate mTLS at Nginx and pass verified client details to PHP via headers—but only if you trust the proxy and strip spoofed headers at the edge. For first-party mobile or partner integrations, OAuth 2.0 with JWT signing keys is often simpler. Compare approaches in API authentication: JWT vs session vs API keys.
Choosing key algorithms in 2026
RSA 2048-bit keys remain widely supported. ECDSA P-256 and Ed25519 offer smaller keys and faster operations. Let's Encrypt supports ECDSA end-entity certificates; many internal PKI tools do as well. Read RSA vs Ed25519 for keys before you standardise a fleet-wide template.
For SSH server access—adjacent but separate from X.509 PKI—key-only auth reduces password spray risk. Our SSH key-only auth setup guide pairs well with proper certificate hygiene on the same hosts.
Cloud PKI suits teams running workloads on AWS or Azure who want automatic renewal at the load balancer. You still need to understand what the client sees at the trust layer. Our API development service includes auth design where mTLS, JWT, or OAuth fit the integration model.
How should you rotate, revoke, and store private keys safely?
Certificate expiry is a feature, not a bug. Short lifetimes limit the window a stolen key remains useful. Automation beats calendar reminders. A cert that expires on a Friday night takes down payments, booking forms, and admin login alike.
Revocation matters when a key is compromised before expiry. OCSP stapling reduces client latency; CRLs remain a fallback. For internal CAs, maintain a documented revocation procedure and audit log.
Private key storage rules that survive audits
- File permissions
600owned by the web-server or deploy user—not world-readable. - Never store keys in Git, Slack, or ticket attachments.
- Use a secrets manager or encrypted CI variables for deploy pipelines.
- Generate CSRs on the target host when possible so the private key never travels.
- Rotate after staff departures who had access to cert stores or HSM pins.
Generate strong passphrases for manual keys with our password generator tool. Encode or inspect PEM payloads with the Base64 encoder and decoder when debugging config—not for storing secrets long term.
On Deployer 7 pipelines I run for sister legal-tech sites, shared .env and storage paths persist across releases while cert paths point to Let us Encrypt live directories outside the release folder. That layout prevents symlink swaps from breaking TLS paths. See support and maintenance services for ongoing cert monitoring after launch.
Compliance-minded clients sometimes ask about digital signatures on PDF affidavits or notarised scans. That is a different EKU profile from TLS web server auth. Adobe Approved Trust List programs and local regulations govern whether a signature is legally recognised—not merely whether the bytes verify cryptographically. Technical correctness is necessary; legal validity is a separate checklist.
Key Takeaways
- PKI binds identities to public keys through CA-signed X.509 certificates validated in a chain of trust.
- Public Let's Encrypt certs suit customer-facing sites; private or cloud PKI fits internal mTLS and managed fleets.
- Always serve the full certificate chain and automate renewal with post-hook service reloads.
- Protect private keys with filesystem permissions, secrets managers, and zero Git exposure.
- Monitor expiry externally—do not rely on Certbot alone without alerting.
- Separate TLS web certificates from code-signing or document-signing certificate profiles.
People Also Ask
Is PKI the same as SSL or TLS?
Not exactly. SSL and TLS are protocols that encrypt traffic in transit. PKI is the trust system that supplies and validates the certificates TLS uses during the handshake. You can run TLS with self-signed certs outside a formal PKI, but browsers will not trust them without manual exceptions.
What is a Certificate Authority in PKI?
A Certificate Authority is an entity that signs certificates after verifying the applicant controls the identity claimed—domain DNS for public DV certs, or organisational documents for OV/EV. Root CAs are trusted by operating systems; intermediate CAs issue the leaf certificates servers present.
Do I need PKI for a small business website in Nepal?
Yes, if you accept logins, payments, or personal data. A free DV certificate from Let's Encrypt delivers the same browser trust as paid certs for basic HTTPS. Local businesses benefit from HTTPS for SEO and for customer confidence—especially on legal, travel, and eCommerce sites serving NPR payments.
How long should TLS certificates last?
Public CAs now issue increasingly shorter lifetimes—90 days is standard for Let's Encrypt. Shorter lifetimes push teams toward automation. Plan renewal at 30 days before expiry and test with certbot renew --dry-run after every infrastructure change.
Build PKI into your stack from day one
Public Key Infrastructure (PKI) Explained is not academic cryptography—it is the trust layer under every HTTPS URL, signed webhook, and secure client portal you ship. Automate issuance, serve complete chains, monitor expiry, and keep private keys out of repositories. Whether you run a Laravel booking app, a WooCommerce store, or a law-firm document portal, PKI hygiene prevents outages that no application log will clearly explain.
Need help wiring TLS, internal mTLS, or certificate automation on Ubuntu production servers? Review our portfolio of shipped platforms, read more on the blog, or contact us to audit your current certificate setup before the next expiry window hits.
Frequently Asked Questions
PKI is the trust framework that binds identities to public keys using CA-signed X.509 certificates, trust stores, and chain validation so clients can verify who they are connecting to.
No. SSL and TLS encrypt traffic in transit; PKI supplies and validates the certificates TLS uses during the handshake. Self-signed certs can run TLS outside formal PKI, but browsers will not trust them without manual exceptions.
Public CAs issue shorter lifetimes now; Let's Encrypt standard is 90 days. Plan renewal around 30 days before expiry and test with certbot renew --dry-run after infrastructure changes.
A Certificate Authority is an entity that signs certificates after verifying the applicant controls the claimed identity—DNS for public DV certs, organisational documents for OV or EV. Root CAs sit in operating system trust stores; intermediate CAs issue the leaf certificates your server presents. Browsers and API clients only trust connections when the chain leads to a root they already know. On production Linux boxes I maintain, that validation happens in Nginx, Apache, or a load balancer before PHP-FPM ever sees the request.
The server sends its leaf certificate plus intermediates; the client builds a chain from leaf to trusted root, checking each signature, hostname against Subject Alternative Names, validity dates, and often revocation. Any broken link triggers a browser warning or silent API failure such as cURL error 60. I have seen Laravel apps work locally over HTTP and fail in staging because staging used an internal CA the server trust store did not recognise. Always serve the full chain—Apache and Nginx need fullchain.pem, not just the leaf.
Yes, if you accept logins, payments, or personal data. A free DV certificate from Let's Encrypt delivers the same browser trust as paid certs for basic HTTPS. For public law-firm and eCommerce sites I have shipped, such as Notary Nepal and Court Marriage In Nepal, Let's Encrypt is the default: free, auto-renewable, and trusted everywhere. HTTPS also supports SEO and customer confidence, especially on legal, travel, and eCommerce sites handling NPR payments. The operational cost is mainly setup and renewal automation, not the certificate itself.
The cryptography is identical; only the trust anchor differs. Public CAs like Let's Encrypt or DigiCert are trusted globally in browser and OS stores—ideal for customer-facing sites, costing free to hundreds of USD per year with ACME automation. Private or internal CAs are trusted only where you install the root—suited to microservices mTLS, VPN, and dev or staging, with low direct cost but you own rotation and audit. Cloud-managed PKI through AWS ACM or Azure Key Vault trades per-cert pricing for less HSM operations. HashiCorp Vault's PKI secrets engine sits between full Microsoft AD CS and manual cert management.
On Ubuntu I typically use Certbot with the webroot or nginx plugin. Point DNS A or AAAA records to the server, open ports 80 and 443, then request certs for every SAN you need. Configure the web server to reference /etc/letsencrypt/live/domain/fullchain.pem and privkey.pem, not paths inside a Deployer release folder. Add a cron or systemd timer for certbot renew plus a deploy hook that reloads Nginx or Apache so PHP-FPM workers pick up the new cert. Run certbot renew --dry-run after every infrastructure change and monitor expiry externally—a failed Friday-night renewal takes down payments and admin login alike.
If you serve only the leaf certificate without intermediate CAs, some clients cannot build a complete chain to a trusted root. Desktop Chrome may still work while Android devices and certain API libraries fail silently with TLS handshake errors. This is one of the most frustrating production bugs because it looks fine from your own browser. The fix is straightforward: point SSLCertificateFile or ssl_certificate at fullchain.pem, which bundles leaf plus intermediates. Certbot on Ubuntu stores these under /etc/letsencrypt/live/domain/ with symlinks. Our hosting setup includes TLS configuration partly because this chain detail catches small teams off guard.
Standard HTTPS TLS proves the server identity to the client. Mutual TLS also proves the client identity to the server—each side presents a certificate and the server verifies the client cert against a trusted CA or allow-list. This fits machine-to-machine calls better than long-lived API keys embedded in config files, especially for internal APIs not exposed to the public internet. Laravel 12 and 13 apps can terminate mTLS at Nginx and pass verified client details via headers, but only if you trust the proxy and strip spoofed headers at the edge. For first-party mobile or partner integrations, OAuth 2.0 with JWT signing keys is often simpler to operate.
Certificate expiry is intentional—short lifetimes limit damage from stolen keys, so automate renewal instead of calendar reminders. Revoke promptly when a key is compromised before expiry; use OCSP stapling for client latency and CRLs as fallback. Store private keys at filesystem permissions 600 owned by the web-server or deploy user, never in Git, Slack, or ticket attachments. Use a secrets manager or encrypted CI variables in Deployer pipelines. Generate CSRs on the target host when possible so the private key never travels. Rotate after staff departures who had access to cert stores, and reload Nginx or PHP-FPM after renewal so workers pick up new material.
A CSR contains the public key plus subject details such as domain name and organisation. You generate it alongside a private key on the server, send the CSR to a CA, and the CA returns a signed X.509 certificate binding that public key to your identity. You need a CSR whenever requesting a new cert from a public CA, internal CA, or cloud PKI service. Best practice on production hosts is generating the CSR where the private key will live so the key never crosses the network. Inspect PEM payloads with openssl or a Base64 decoder when debugging config, but never use those tools for long-term secret storage.
The private key stays on disk, in a vault, or HSM and must never be committed to Git. The CSR carries the public key and identity details for CA signing. The X.509 certificate binds identity to the public key and includes validity window, Subject Alternative Names, and extensions such as Extended Key Usage. The trust store holds root and intermediate CA certificates clients already trust. CRL and OCSP let verifiers check revocation before expiry. RFC 5280 defines the X.509 v3 fields browsers and CAs implement. The same machinery serves HTTPS, code signing, email S/MIME, VPN auth, and document signing—only the EKU profile changes.
RSA 2048-bit keys remain widely supported across legacy clients and load balancers. ECDSA P-256 and Ed25519 offer smaller keys and faster cryptographic operations, and Let's Encrypt supports ECDSA end-entity certificates. Before standardising a fleet-wide template, read up on RSA versus Ed25519 trade-offs for your client base. Many internal PKI tools support the same options. Algorithm choice is separate from SSH key auth, which uses its own key format adjacent to but distinct from X.509 PKI. Pick one standard per environment and document it so renewal automation does not mix incompatible key types across vhosts.
Both use X.509 and PKI primitives, but Extended Key Usage flags define what each cert may do. A TLS web server certificate proves domain identity for HTTPS handshakes. A document-signing certificate applies digital signatures to PDFs such as affidavits or notarised scans—a different profile entirely. Cryptographic verification of bytes is necessary but not sufficient for legal validity; Adobe Approved Trust List programmes and local regulations determine whether a signature is recognised in court or by government offices. Compliance-minded clients on legal portals sometimes conflate the browser padlock with legally binding e-signatures. Keep TLS certs and document-signing certs on separate profiles and renewal schedules.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
