Your website shows a security warning. Whose fault is it?
One command answers that, and the answer usually decides whether you have to pay anybody.
If Chrome shows visitors a full-page red page saying your connection is not private before your site loads, the certificate being served does not match your domain. The useful question is not what is wrong. It is whose certificate is it. That single fact tells you who has to fix it.
Read the certificate yourself
On a Mac or Linux machine, replacing the domain with yours. Nothing is submitted and nothing changes. It opens a connection and prints what was served.
echo | openssl s_client -servername www.yourpractice.com \
-connect www.yourpractice.com:443 2>/dev/null \
| openssl x509 -noout -subject -issuer -datesThe subject line is the answer. notAfter tells you whether it has expired.
What the subject line means
A wildcard belonging to your website vendor
CN=*.prosites.com, CN=*.internetbrands.com, CN=*.secureserversites.net
Your domain points at their servers and no certificate was ever issued for your name. The fix is theirs and should cost you nothing. This was the single most common cause in everything I checked.
A wildcard belonging to your host
CN=*.wpengine.com, CN=*.squarespace.com, CN=sni.dreamhost.com, CN=*.hostgator.com
Same shape, different party. The site is parked on shared infrastructure with SSL never attached to your own domain, or the domain was added after the certificate was issued.
Your own certificate, expired
CN=yourpractice.com with a notAfter date in the past
Auto-renewal stopped. Very often because the renewal notice goes to an email address nobody reads any more, usually a former office manager, or the person who built the site in 2014.
Your own certificate, missing the www
CN=yourpractice.com but visitors hit www.yourpractice.com
A near miss, and easy to miss: whoever set it up tested the bare domain and it worked. Directory listings and old bookmarks mostly point at the www version.
Self-signed
subject and issuer are the same name
The server is presenting a certificate it made itself. No browser will ever accept it. One practice I checked had been serving a self-signed certificate that expired in February 2019.
What I found across 95 practices
Out of roughly 1,500 US dental practices checked, 95 had a certificate fault. When I read the certificate actually being served on each one, the result was not a scatter. 14 of the 95 were serving the same vendor’s wildcard certificate, and a further handful belonged to two other platforms. Most of the rest were a practice’s own certificate, expired.
The practical implication is worth stating plainly: if your site is broken this way, it is quite likely not something you did, and not something you should be paying to fix. Send your provider the exact subject line and the error string and ask them to issue a certificate covering your domain.
Why nobody in the practice noticed
Because you cannot see it. Staff open the site from a bookmark on a machine that stored a certificate exception the day it broke, so it looks entirely normal from the front desk. The warning is shown only to somebody arriving fresh, which is every prospective patient clicking your Google result. The practices in that list have been broken for weeks or months and none of them had reported it.
If you would rather not run a command
Email me the domain at ishubham2101@gmail.com and I will check it and tell you what is being served and who has to fix it. No charge and no signup, and it takes me about a minute. If you manage a list of practices or sites and want all of them checked at once, that is the thing I actually sell.