X.509 digital certificates are a fantastically secure method of authentication, but they require a little more infrastructure to support than your typical username and password credentials. A frequent error encountered by users attempting to configure and install their own certificates is:
“X.509 Certificate Signed by Unknown Authority”
This article is going to break down the most likely reasons you’ll find this error code, as well as suggest some digital certificate best practices so you can avoid it in the future.
Cause of X.509 Certificate Error
By far, the most common reason to receive the “X.509 Certificate Signed by Unknown Authority” error is that you’ve attempted to use a self-signed certificate in a scenario that requires a trusted CA-signed certificate. Most of the examples we see in the field are self-signed SSL certs being installed to enable HTTPS on a website.
While self-signed certificates certainly have their place, they are inappropriate to use for public-facing operations (like a website on the internet). Typically, public-facing certificates are signed by a public Certificate Authority (CA) that is recognized and trusted by major internet browsers and operating systems. This system makes intuitive sense, would you rather trust someone you’ve never heard of before or someone that is being vouched for by other ‘people’ you already trust?
Self-signed certificates are only really useful in a few scenarios, such as intranet, home-use, and testing purposes.
You probably still need to sort out that HTTPS, so here’s what you need to do.
Solution for “Certificate Signed by Unknown Authority”
This may not be the answer you want to hear, but it’s been staring at you the whole time – get your certificate signed by a known authority. In other words, acquire a certificate from a public certificate authority.
Depending on your use case, you have options.
If you do simply need an SSL certificate to enable HTTPS, there are free options to get your trust certificate. Your web host can likely sort it out for you, or you can go to a service like LetsEncrypt for free trusted SSL certs.
In some cases, it makes sense to buy a trusted certificate from a public CA like Digicert. If you need to digitally sign an important document or codebase to ensure it’s tamperproof, or perhaps for authentication to some service, that’s the way to go.
Note that using self-signed certs in public-facing operations is hugely risky. It’s trivial for bad actors to inspect a certificate, and self-signed certificates are a skeleton key for the holder that could allow nearly unfettered access, depending on the configuration.
Fortunately, there are solutions if you really do want to create and use certificates in-house. In fact, it’s an excellent idea since certificates can be used to authenticate to Wi-Fi, VPN, desktop login, and all sorts of applications in a very secure manner.
Managed PKI for Effective Certificate Management and Creation
For most organizations, working with a 3rd party that manages a PKI for you is the best combination of affordability and manageability. SecureW2 is a managed PKI vendor that’s totally vendor neutral, meaning it can integrate into your network and leverage the existing components with no forklift upgrades.
What’s more, if your organization is stuck with on-prem infrastructure like Active Directory, SecureW2’s PKI can upgrade your infrastructure to become a modern cloud network replete with the innumerable benefits of cloud computing like easy configuration, no physical installation, lower management costs over time, future-proofed, built-in redundancy and resiliency, etc.
Our comprehensive management tools allow for a huge amount of flexibility for admins. It provides a centralized place to manage the entire certificate lifecycle from generation to distribution, and even supports auto-revocation features that can be extended to MDMs like Jamf or Intune. The intuitive single-pane management interface includes advanced reporting and analytics with complementary AI-assisted anomaly detection to keep you safe even while you sleep.
Certificates distributed from SecureW2’s managed PKI can be used for SSL, S/MIME, RADIUS authentication, VPN, web app authentication, and more. If this is your first foray into using certificates and you’re unsure where else they might be useful, you ought to chat with our experienced support engineers.
Overall, a managed PKI simplifies the certificate experience and takes the burden of complex management, certificate configuration, and distribution off of your shoulders so you can focus on what matters. Check out SecureW2’s pricing page to see if a managed PKI solution can simplify your certificate management experience and eliminate x509 errors.
Fixing Self-Signed Certificates in Docker
A bunch of the support requests that come in regarding “Certificate Signed by Unknown Authority” seem to be rooted in users misconfiguring Docker, so we’ve included a short troubleshooting guide below:
Docker is a platform-as-a-service vendor that provides tools and resources to simplify app development. It’s an excellent tool that’s utilized by anyone from individuals and small businesses to large enterprises.
Unfortunately, some with a lack of understanding of digital certificates and how they work accidentally use self-signed certificates with Docker. As discussed above, this is an app-breaking issue for public-facing operations. If a user attempts to use a self-signed certificate, they will experience the x509 error indicating that they lack trusted certificates.
Some smaller operations may not have the resources to utilize certificates from a trusted CA. Configuring, provisioning, and managing certificates is no simple endeavor and can be costly if improperly handled. Of course, if an organization needs to use certificates for a publicly used app, their hands are tied. What is the best option available to add an easy-to-use certificate authority that can be used to check against and certify SSL connections?
Solutions for “x509 Certificate Signed by Unknown Authority” in Docker
- Perhaps the most direct solution to the issue of invalid certificates is to purchase an SSL certificate from a public CA. Public CAs, such as Digicert and Entrust, are recognized by major web browsers and as legitimate. This is codified by including them in the root store of devices and browsers, a preconfigured list of trusted root certificates.
- If you’d prefer to continue down the path of DIY, check out this Docker forum post detailing a successful attempt to configure your own CA and issue certificates from it. You’ll still end up with self-signed certs inappropriate for SSL, but the error should be resolved.
