It is one of the longest error messages in SQL Server, and it frightens people into reinstalling things that were never broken. Read it slowly and it is actually a precise report: the connection worked, the login stage failed, and the reason is certificate trust. This guide translates each line into plain language.
Most SQL Server errors are one short line. This one is a paragraph, and every sentence in it rules something in or out. Established, then failed during login, inside the SSL provider, because the certificate chain is not trusted - four facts that point to exactly one cause. Once you can read it, you will never troubleshoot the wrong thing again.
A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.)
The message opens with good news most people skip: a connection was successfully established. That single line clears half the usual suspects. The server machine is reachable, the port answers, SQL Server is running, and the firewall let you through. Do not waste an hour on cables, ping tests and port checks - the error itself has already told you the network path works.
The failure sits in the login process, before any database opens. At this stage SQL Server protects the password exchange by opening a TLS (encrypted) channel, and for that it presents a certificate, the same way a website presents one to your browser. The login never got as far as checking your username or password. That is why even the correct password fails, and why entering it again and again changes nothing.
SSL Provider is the Windows security layer that builds the encrypted channel. Error 0 here is a generic failure code from that layer - it carries no extra information by itself. The useful part is the sentence that follows it.
This is the whole diagnosis in one sentence. A certificate is believed when it chains up to a trusted authority - a known organisation that vouches for it. SQL Server, when nobody has installed a certificate on it, presents a self-signed one: the server vouching for itself. Your PC answers, correctly, that a stranger's signature proves nothing. The chain is broken at the very first link, so the client refuses the channel and the login dies with it.
Three honest ways out exist. The client can be told to trust this server anyway (the one click fix), the client can be given the server's certificate to trust directly, or the server can be given a properly signed certificate so no special trust is needed. The main guide on this page walks all three in order.
It is not a wrong password (the password was never checked). It is not a corrupt database (no database was opened). It is not the server being down (the server just answered you). And it is not a virus or an attack - it is your own client doing exactly the security check it was designed to do, possibly because a newer tool version turned that check on. Naming the problem correctly is what makes the fix take one minute instead of one day.
In the video the error is fixed on screen in about a minute once its meaning is clear. Watch the fix being applied to this exact dialog.
▶️ Watch Full VideoNo. It almost always means your own server is presenting its self-signed certificate and your own client is refusing it. An attack is theoretically what the check guards against, but in daily office life the cause is a missing real certificate.
SSL and its modern form TLS are the standard way to encrypt and authenticate a connection, and SQL Server uses the same Windows security provider for its login channel. The word provider in the message names that Windows component.
Not really. Error 0 from the SSL provider is a general failure marker. The sentence after it, about the certificate chain, is where the actual information lives.