Encryption in Transit, Encryption at Rest, PKI, and Certificates
Key Takeaways
- Encryption in transit protects data while it crosses a network; encryption at rest protects stored data.
- Symmetric encryption is efficient for bulk data, while asymmetric encryption supports key exchange, signatures, and identity validation.
- PKI uses certificate authorities, certificates, public keys, private keys, and trust chains to support secure communication.
- Certificates should be validated for name, expiration, issuing CA, trust path, and revocation status.
- Network+ questions usually focus on where encryption is used and what problem a certificate or key solves.
Encryption, PKI, and Certificates
Network security often starts with a simple question: what data needs protection, and where is it 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, mobile device, or removable storage.
Encryption in Transit and at Rest
| Protection target | Common examples | Primary goal |
|---|---|---|
| Data in transit | HTTPS, TLS, SSH, IPsec VPN, WPA3, secure email transport | Prevent eavesdropping and tampering while traffic moves |
| Data at rest | Full-disk encryption, database encryption, encrypted backups, encrypted object storage | Protect stored data if media, accounts, or systems are accessed improperly |
| Data in use | Memory, active application processing, live sessions | Usually handled by access control, application security, and endpoint protection |
In transit controls are visible in network design. Examples include HTTPS for web portals, SSH instead of Telnet for device administration, SNMPv3 instead of SNMPv2c for management polling, and IPsec or SSL/TLS VPNs for remote access.
At rest controls are usually applied closer to storage. A laptop with full-disk encryption protects data if the device is lost. Encrypted backups protect archived data if backup media is mishandled. Database or column encryption can protect selected fields such as payment or identity data.
Symmetric and Asymmetric Cryptography
| Method | How it works | Strength | Common network use |
|---|---|---|---|
| Symmetric encryption | Same secret key encrypts and decrypts | Fast for bulk data | TLS session encryption, VPN payload encryption, Wi-Fi encryption |
| Asymmetric encryption | Public and private key pair | Useful for identity and key exchange | Certificate validation, digital signatures, secure key exchange |
| Hashing | One-way digest of data | Detects change, does not encrypt | File integrity checks, certificate fingerprints |
| Digital signature | Hash encrypted with a private key | Supports integrity, identity, and non-repudiation | Signed certificates, signed code, signed messages |
Most secure protocols use a combination. For example, TLS uses certificates and asymmetric operations to authenticate and establish trust, then uses symmetric keys to encrypt the session efficiently.
PKI at Network+ Depth
A public key infrastructure, or PKI, is the system that lets endpoints decide whether a certificate should be trusted.
| PKI component | Purpose |
|---|---|
| Certificate authority (CA) | Issues and signs certificates |
| Root CA | Top-level trust anchor installed in trusted stores |
| Intermediate CA | Issues certificates while keeping the root CA protected |
| Certificate | Binds a public key to a subject name and issuer |
| Private key | Secret key held by the certificate owner |
| CSR | Certificate signing request submitted to a CA |
| CRL or OCSP | Revocation checking methods |
When a user browses to an internal portal, the client checks that the certificate name matches the site, the certificate has not expired, the issuing CA is trusted, the certificate path chains to a trusted root, and the certificate has not been revoked. A warning can appear if any of those checks fail.
Certificate Scenarios
| Symptom | Likely certificate issue | Practical fix |
|---|---|---|
| Users see a name mismatch warning | Certificate subject or SAN does not match the hostname | Reissue with the correct DNS name |
| Works on domain laptops but not guest devices | Internal CA is trusted only by managed systems | Use a public CA or install the internal root where appropriate |
| Service fails after a known date | Certificate expired | Renew and deploy before expiration |
| Private key may be exposed | Key compromise | Revoke and replace the certificate and key |
| TLS inspection breaks an application | Client does not trust inspection CA or uses certificate pinning | Adjust inspection policy or trust deployment |
Common Traps
- Encrypting a disk does not protect data once a logged-in user opens the file.
- Using HTTPS does not prove an application is authorized; it proves the connection is encrypted and the certificate was trusted.
- A public key can be shared. A private key must be protected.
- A self-signed certificate can encrypt traffic, but clients need a reason to trust it.
- Hashing is not encryption because it is not designed to be decrypted.
Exam Focus
For Network+ N10-009 Domain 4, expect practical questions about choosing secure protocols, recognizing certificate errors, replacing insecure management methods, and identifying whether the issue is confidentiality, integrity, authentication, or trust.
A network administrator replaces Telnet with SSH for switch administration. What is the main security improvement?
Users receive a browser warning after a web server certificate is renewed for server01.local, but they access the site as portal.example.com. What is the likely issue?
Which statements about PKI are accurate? Select three.
Select all that apply