A marketing team launches a new storefront and asks IT for "a certificate." Before anyone can order one, someone has to answer four questions: who needs to trust it, which names it must cover, how much identity vetting the business wants, and what the key will be used for. Each answer points to a different kind of certificate, and the wrong choice either breaks the site or quietly weakens it.
On the CompTIA Security+ SY0-801 exam, certificate types sit under objective 1.3, which expects you to explain why choosing the right cryptographic solution matters, including self-signed, third-party and wildcard certificates. This lesson covers who trusts each type, how wildcard and SAN certificates handle names, what the DV, OV and EV validation levels mean, and which certificates identify people, machines and software instead of websites.
Self-signed certificates are acceptable only when you control every client
A self-signed certificate is signed with its own private key. The issuer and subject are the same, and no certificate authority vouches for it. Creating one takes a single command:
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -noenc \
-keyout lab01.key -out lab01.crt -days 365 \
-subj "/CN=lab01.corp.example.com" \
-addext "subjectAltName=DNS:lab01.corp.example.com"
On Windows, the PowerShell equivalent creates the certificate and its key in the computer's certificate store:
New-SelfSignedCertificate -DnsName "lab01.corp.example.com" -CertStoreLocation "Cert:\LocalMachine\My"
The encryption is exactly as strong as with a CA-issued certificate. What's missing is identity assurance. A client has no way to tell your self-signed certificate from one an attacker generated with the same name, unless someone has told that client in advance to trust that exact certificate.
Self-signed certificates are reasonable in a few places:
- Labs, development and test systems that only their builders use.
- The first-boot management interface on a switch, printer, hypervisor or server management controller, until a proper certificate replaces it.
- Service-to-service connections where both ends are configured to trust one specific certificate.
- Root CAs. Every root certificate is self-signed, and it is trusted because it was placed in the trust store on purpose.
They are a poor choice for anything public or anything people use daily. The deeper damage is behavioral: employees who click through a "Your connection is not private" warning on the intranet every morning will click through the same warning when an attacker is intercepting their traffic. On the exam, "lab," "testing" or "development" with no outside users makes self-signed acceptable. A scenario where users keep seeing warnings on an internal site points to replacing the certificate with one from an internal CA whose root is pushed to company devices, not to telling users to accept the warning.
Third-party certificates borrow trust that devices already have
A third-party certificate is issued by a CA other than the subject itself. On the exam the term usually means a public commercial CA, whose roots are already in the trust stores of every major operating system and browser. An internal enterprise CA is technically a third party to the server it certifies, but only managed devices trust it.
The reason to use a public CA is zero client configuration. Customers, partners, contractors and phones you will never manage all trust the certificate the moment it is installed. For a public website, API or mail server, that is the only workable option.
The trade-off is that public CAs follow rules set by the CA/Browser Forum and the browser root programs. They issue only for public domain names you can prove you control, they cap how long certificates last, and every TLS certificate they issue is recorded in public Certificate Transparency (CT) logs. CT lets a domain owner spot a certificate issued for its domain without permission, which is how several mis-issuance incidents came to light. It also means every hostname you put in a public certificate becomes searchable, so a certificate for vpn-test.example.com tells attackers that the host exists. Keep that in mind for the next two certificate types.