Blog
An end to certificate chaos
Principal Consultant
Consultant
Why a Windows PKI is no longer enough
Anyone running a Microsoft-only environment relies on the Windows Public Key Infrastructure (PKI). This is secure and efficient as long as you stay within the boundaries of Active Directory. In practice, however, a purely Windows-based infrastructure is rare. What happens on the edges of these infrastructures?
For Linux servers, firewalls, load balancers, or container platforms, it is not possible to automatically access certificates from the Windows environment. This creates a security vulnerability that administrators can often resolve only with considerable manual effort.
Why we need certificates
In today’s modern security architectures, the “zero trust” principle applies. Certificates are required at an increasing number of endpoints to ensure secure and encrypted communication.
Certificates can be obtained automatically via the Automated Certificate Management Environment (ACME) protocol from providers such as Actalis SSL or Let’s Encrypt. It is crucial that validation of the resource in question can be performed by an external authority, a certification body, via the Internet. This requires that the resource’s name be resolvable on the Internet so that the verification can be performed successfully.
And right there lies the real challenge: Without a publicly accessible and routable domain for internal endpoints, it is not possible to automatically issue certificates via ACME for internal systems.
The trap of manual management and short-lived certificates
For many administrators, the reality is harsh: They often have to manually request certificates for systems that are not accessible from the outside, copy them, and distribute them to the systems.
The risks of manual allocation
- Human error: A certificate expires because the calendar reminder entry was missing or was overlooked. As a result, critical services are unavailable, and troubleshooting can take several hours under some circumstances.
- Long validity periods: To minimize administrative burdens, certificates are often issued with terms of more than one year. From a security standpoint, this is a cause for concern: The longer the validity period, the greater the window of opportunity for potential misuse of compromised keys.
Most browsers now only accept certificates with a validity period of about one year. In fact, the trend is clearly moving toward even shorter validity periods – like with Let’s Encrypt, where certificates are currently valid for only 90 days. But having to manually renew certificates every 90 days puts the brakes on your IT department. The administrative burden is enormous.
The solution: A single web service for all systems
A central ACME service, operated as a web service on the internal network, provides a solution. It enables the distribution of certificates to all clients. The strength of this web service is its flexibility. Since the ACME protocol is an open standard, there are ready-made clients available for almost every system. It doesn’t matter at all whether it’s a KEMP or Fortinet firewall, a Docker container, or a Windows server without an Active Directory connection.
The advantages:
- Universal compatibility via Windows and beyond: While Windows PKI excludes all clients that do not support Kerberos authentication, this service enables the fully automated provisioning of certificates to all systems on the network.
- Increased security through a short validity period: Modern security standards, such as short-validity certificates, can be easily implemented internally, since the renewal process runs automatically in the background.
- Preventing outages: The risk of human error is eliminated by the higher degree of automation. This significantly improves the operational stability of the services.
- Standardization: Using a standardized protocol across different manufacturers and operating systems makes it easier to diagnose errors.