A browser shows a padlock because something it already trusted vouched for your certificate. Where that trust comes from is worth understanding, because it explains several problems that otherwise look unrelated.
The root store
Every device ships with a list of certificate authorities it trusts. A root store, maintained by the operating system or the browser vendor.
Getting onto that list is difficult and slow. Authorities are audited, and they are removed when they fail those audits, which has happened to well-known ones.
That list is the foundation of the entire system. Nothing in a certificate makes it trustworthy; the device's list does.
The chain
Roots are kept offline and used rarely. They sign intermediate authorities, and intermediates sign the certificates issued to websites.
So verification walks a chain: your certificate was signed by an intermediate, which was signed by a root, which is on the device's list.
The practical consequence: your server must send the intermediate certificates, because the device has the root and your certificate but not the piece between them.
This is the single most common certificate misconfiguration, and its symptom is distinctive; the site works in a desktop browser, which has the intermediate cached from another site, and fails on a phone or from a script. Understanding the certificate chain goes into fixing it, and checking a certificate from the command line shows whether yours are being sent.
Why self-signed certificates are refused
A self-signed certificate signs itself. The chain leads back to nothing on the device's list, so there is nothing to verify against.
The encryption is exactly as strong. What is missing is any statement, from anyone the device trusts, that the server is who it claims. That is the part being refused.
Which makes self-signed certificates fine for a machine talking to itself and unsuitable for anything a visitor reaches, and free trusted certificates removed most reasons to use them anyway.
Why old devices fail on sites that work everywhere else
The root store is updated with the device. A phone or television that stopped receiving updates has a list frozen at that moment.
When a newer root is introduced, or an older one expires, that device no longer has a path to verify certificates signed under it, while every current device is fine.
This has caused real, widespread outages on old devices with no change on the server at all. The server cannot fix it; only the device's list can be updated, and on an abandoned device it cannot.
Worth knowing when a customer reports a certificate error nobody else can reproduce and everything checks out.
Why corporate networks can read encrypted traffic
An organisation that wants to inspect traffic installs its own root on every machine it manages.
Their equipment then issues certificates for whatever site is requested, signed by that root. The browser verifies against the list, finds the organisation's root, and shows a padlock.
Nothing is broken. The trust model worked exactly as designed. The device was told to trust that authority.
It is also why "the connection is encrypted" and "nobody can read it" are not the same statement on a managed device. What a certificate does not protect explains the other edges of the same guarantee.
What this means for your server
Three practical points follow.
Send the full chain. Not just your certificate. Most panels handle this; verify rather than assume.
Use a widely trusted authority. The free automated ones are on every current device's list, which is the only property that matters here.
Do not ask visitors to install anything. Any instruction to trust a certificate manually is training people to click through warnings, which is the behaviour the whole system depends on them not having.
Free versus paid certificates walks through choosing between authorities, and the trust question is identical for both.
Inspect what a client actually trusts
The abstract explanation becomes concrete when you look at the list on a machine.
ls /etc/ssl/certs/ | head -20
awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{c=cmd} c{print | c} /END/{close(c); c=0}' \
/etc/ssl/certs/ca-certificates.crt 2>/dev/null | head -20
That prints the names of the authorities this machine trusts. It is a longer list than most people expect: typically well over a hundred organisations, in many jurisdictions, each of which can issue a certificate for any domain.
That breadth is the system's main weakness and the reason for the monitoring described below: trust is only as strong as the least careful authority on the list.
Certificate transparency closes part of the gap
Because any authority can issue for any domain, there needs to be a way to notice when one does so without your involvement.
Public logs record every certificate issued, and they are searchable. Monitoring services will alert on a new certificate for your domain, which is frequently the earliest signal available that something is wrong: earlier than any DNS check.
Setting one up takes minutes and costs nothing, and the alert it produces is unambiguous: a certificate you did not request means somebody demonstrated control of your domain to an authority. Monitoring DNS and detecting unauthorised changes goes into the mechanism that would have allowed it.
Restricting who may issue for your domain
A CAA record states which authorities are permitted to issue certificates for a domain, and compliant authorities check it before issuing.
example.com. IN CAA 0 issue "letsencrypt.org" example.com. IN CAA 0 iodef "mailto:[email protected]"
The first line restricts issuance; the second asks for a report when a request is refused.
It is not a strong control: it depends on authorities honouring it, and it is a cheap one that narrows the list of who can issue for you from everybody to whoever you named. Add the authority your host actually uses before adding the record, or renewals fail. Understanding CAA records explains the syntax.
Expiry is shortening, which changes the arithmetic
Certificate lifetimes have fallen steadily and continue to. A certificate valid for a year is already unusual; shorter periods are becoming standard.
The practical consequence is that manual renewal has stopped being viable. A process that worked when it happened annually fails when it happens every few weeks, and the failure is silent until visitors see a warning.
Automation is therefore no longer an optimisation but the only workable arrangement, and monitoring the expiry independently of the renewal is what catches an automation that has quietly stopped. Checking a certificate from the command line walks through the check.