Every certificate described below encrypts in exactly the same way. A domain validated certificate issued in forty seconds and an extended validation certificate issued after a fortnight of paperwork produce an identical connection: the same ciphers, the same key exchange, the same padlock. What you are choosing between is not strength. It is two other things, how much the issuer checked before signing, and how many names the signature covers.
That one fact settles most of the question, and most writing on the subject buries it.
What the issuer checked
Domain validated
The certificate authority proves one thing: that whoever asked for the certificate controls the domain. It checks by asking you to publish a file, answer on a particular port, or add a DNS record. Nobody reads a company registration and nobody telephones anyone. Issuance takes minutes and is normally automated from end to end. For a brochure site, a blog, an application or an API, this is the correct certificate, and buying a different kind adds nothing a visitor or a browser will ever act on.
Organisation validated
The same domain check, plus verification of the legal entity behind it: registration number, trading address, often a call to a telephone number the authority finds independently rather than one you supply. It takes days rather than minutes, and the verified company details are written inside the certificate, where a visitor can see them by opening the padlock and asking for details.
Extended validation
The organisation check again, stricter and slower, against a published set of criteria. The thing EV was sold on no longer exists: browsers removed the company name from the address bar in 2019, so there is no green bar and nothing visually separates it from a certificate issued automatically in under a minute. It is still worth buying when a contract, a regulator or an auditor asks for it by name. That is a real reason. "It looks more secure to customers" stopped being one years ago.
How many names it covers
- Single name. One hostname. The trap is that a certificate for
example.comdoes not coverwww.example.comunlesswwwis listed on it too. Almost every certificate issued today lists both, precisely because the mistake was so common, but it is worth checking rather than assuming. - Wildcard.
*.example.comcovers every single-label subdomain:shop,api,staging, anything. It does not cover the bare domain unless that is listed separately, and it does not reach a second level such asa.b.example.com. The reason to buy one is subdomains that are created faster than you can validate them individually. - Multi-domain, sometimes sold as SAN or UCC. Several unrelated names on one certificate. Convenient to manage and cheaper than buying each separately. The trade is that every name on it is published in the public certificate transparency logs, so a certificate covering a client's internal hostname announces that the hostname exists.
What you already have here
A free certificate is issued for a domain on a shared hosting account once that domain resolves to the account. It is domain validated. The SSL/TLS Status page in cPanel is where you check which names are currently covered and when the certificate expires, and it is the first page to open when a browser complains, because nine times out of ten the answer is on it.
Buy something else when one of three things is true, and not otherwise: a contract or an auditor names OV or EV; you need one certificate across subdomains that come and go; or the certificate has to be installed somewhere that is not a cPanel account. If one of those applies, open a ticket and describe what is being asked for, because the requirement usually names the certificate type and that is the whole of the decision.
The four ways it actually goes wrong
- Expiry. Certificate lifetimes have been getting shorter for years, which makes manual renewal a diary entry somebody will eventually miss. Automated issuance exists because of this, not for convenience.
- A name not on the certificate. Usually
www. The browser shows a name mismatch, which reads to a visitor as something considerably worse than an expired certificate. - Mixed content. The page is served over HTTPS and then loads an image or a script over plain HTTP. The browser either drops the padlock or blocks the resource outright. The cause is nearly always an absolute URL hard-coded in a theme or sitting in the database from before the move.
- An incomplete chain. The certificate works in your browser because it had already cached the intermediate from another site, and fails for a visitor whose browser had not, and fails in almost every API client and payment gateway. A certificate that works on your laptop is not the same thing as a certificate that works.
One thing a certificate does not do
It proves the connection, not the counterparty. A phishing site that registered a lookalike domain this morning has a valid certificate and a padlock by lunchtime, because it does control that domain. The padlock means nobody is reading the traffic in transit. It has never meant the site at the other end is honest, and telling customers to "look for the padlock" as a fraud check has been bad advice for a decade.