Encryption in Transit, Encryption at Rest, PKI, and Certificates
Key Takeaways
- Encryption in transit (TLS, SSH, IPsec) protects data crossing a network; encryption at rest (full-disk, database, backup) protects stored data.
- Symmetric algorithms (AES) are fast for bulk data; asymmetric algorithms (RSA, ECC) handle key exchange, signatures, and identity.
- PKI binds public keys to identities through a CA, root and intermediate certificates, and a trust chain validated by clients.
- Clients validate a certificate's name/SAN match, expiration, trusted issuer, chain to a trusted root, and revocation status (CRL or OCSP).
- Network+ N10-009 Domain 4 questions test where encryption belongs and which problem a certificate, key, or hash actually solves.
Encryption, PKI, and Certificates
Logical security is Domain 4 of the CompTIA Network+ (N10-009) exam and is weighted at 14% of your scored questions. The exam is a maximum of 90 questions in 90 minutes with a passing score of 720 on a 100-900 scale, so a 14% domain represents roughly a dozen items. Cryptography questions here are not math problems; they ask what data needs protecting and where it is exposed.
Data in transit is exposed while it moves across wired, wireless, WAN, VPN, cloud, or Internet paths. Data at rest is exposed when it sits on a disk, database, file share, backup tape, mobile device, or USB drive. Data in use is the cleartext a logged-in application is actively processing in memory.
Encryption in Transit and at Rest
| Protection target | Common controls | Primary goal |
|---|---|---|
| Data in transit | HTTPS/TLS, SSH, IPsec VPN, WPA3, SNMPv3, secure SMTP (STARTTLS) | Stop eavesdropping and tampering while traffic moves |
| Data at rest | Full-disk encryption (BitLocker, FileVault), database/column encryption, encrypted backups, encrypted object storage | Protect stored data if media or accounts are accessed improperly |
| Data in use | Access control, endpoint protection, application security | Cleartext in RAM cannot be decrypted away |
In-transit controls are visible in network design: HTTPS for web portals, SSH instead of Telnet for device administration, SNMPv3 instead of SNMPv2c for polling, and IPsec or SSL/TLS VPNs for remote access. At-rest controls live near storage: a laptop with full-disk encryption is useless to a thief who steals it powered off; encrypted backups survive a lost tape.
Symmetric and Asymmetric Cryptography
| Method | How it works | Strength | Network use |
|---|---|---|---|
| Symmetric (AES-128/256) | One shared secret key encrypts and decrypts | Fast; bulk data | TLS session payload, VPN payload, Wi-Fi (WPA2/WPA3) |
| Asymmetric (RSA, ECC) | Public/private key pair | Slower; identity and key exchange | Certificate validation, signatures, TLS handshake |
| Hashing (SHA-256) | One-way digest, fixed length | Detects change; not reversible | File integrity, certificate fingerprints, password storage |
| Digital signature | Hash encrypted with the signer's private key | Integrity + identity + non-repudiation | Signed certificates, signed code |
Real protocols combine these. A TLS handshake uses the server's certificate and asymmetric operations to authenticate and agree on a key, then switches to a symmetric session key (AES) because asymmetric crypto is far too slow for bulk traffic. That hybrid model is a frequent exam cue.
PKI at Network+ Depth
A public key infrastructure (PKI) is the system that lets an endpoint decide whether a certificate deserves trust.
| PKI component | Purpose |
|---|---|
| Certificate Authority (CA) | Issues and digitally signs certificates |
| Root CA | Top-level trust anchor installed in the trusted root store; kept offline |
| Intermediate CA | Issues end-entity certs so the root stays protected |
| Certificate (X.509) | Binds a public key to a subject name and issuer |
| Private key | Secret held only by the certificate owner |
| CSR | Certificate Signing Request submitted to the CA |
| CRL / OCSP | Revocation checking; OCSP is a real-time lookup, a CRL is a downloaded list |
| SAN | Subject Alternative Name listing every valid hostname |
When a browser opens an internal portal, the client confirms five things: the certificate name or SAN matches the hostname, the certificate has not expired, the issuing CA is trusted, the chain links to a trusted root, and the certificate is not revoked. Any failure produces a warning.
Certificate Troubleshooting Scenarios
| Symptom | Likely cause | Fix |
|---|---|---|
| Name-mismatch warning | Subject/SAN does not match the URL hostname | Reissue with the correct DNS name in the SAN |
| Works on domain PCs, fails on guests | Internal CA trusted only by managed devices | Use a public CA or push the internal root |
| Service breaks on a known date | Certificate expired | Renew and deploy before expiry; automate reminders |
| Suspected key exposure | Private key compromise | Revoke (CRL/OCSP) and reissue cert and key |
| App breaks behind TLS inspection | Client distrusts the inspection CA or uses pinning | Deploy the inspection root or exempt pinned apps |
Common Traps
- Full-disk encryption does not protect a file once an authenticated user opens it.
- HTTPS proves the connection is encrypted and the cert was trusted; it does not prove the app is authorized or safe.
- A public key can be shared freely; a private key must never leave the owner.
- A self-signed certificate encrypts traffic fine, but clients have no reason to trust it, so they warn.
- Hashing is not encryption because it is one-way by design.
Exam Focus
Expect practical N10-009 items: pick the secure protocol, diagnose a certificate warning, replace an insecure management method, or classify whether the problem is confidentiality, integrity, authentication, or trust.
A network administrator replaces Telnet with SSH for switch administration. What is the main security improvement?
Users access a site as portal.example.com, but after renewal the certificate's subject and SAN list only server01.local. What error appears?
Which statement about PKI components is accurate?