2026-09-23 17:36:00
2026-09-23 17:36:00
Let's Encrypt is excellent for public websites. But should you use a publicly trusted SSL certificate for applications that exist only inside your organization?
This question comes up frequently when IT teams want HTTPS for internal HRMS, ERP, CRM, dashboards, SQL administration tools, VPN portals, internal APIs and other web applications.
A common solution is to use Let's Encrypt SSL with the DNS-01 challenge.
It works. But "it works" and "it is the right architecture for an internal application" are two different questions.
For internal-only applications, there are several security and operational considerations worth understanding.
Normally, a Certificate Authority needs to verify that you control a domain before issuing a certificate.
With the DNS-01 challenge, Let's Encrypt does not need to connect to your internal web server.
Instead, you prove control of the domain by publishing a specific TXT record under _acme-challenge.
This means an application can remain completely inaccessible from the Internet while still obtaining a publicly trusted certificate — provided the name is under a publicly registered domain that you control and the DNS validation can be performed publicly.
Let's Encrypt itself confirms that DNS-01 can be used when the server is not exposed to the Internet. (Let's Encrypt Community Support)
For example:
hrms.company.commight resolve internally to:
10.10.20.15The HRMS server does not need to be Internet-accessible.
That sounds ideal.
But there is a catch.
Suppose your internal applications use names such as:
hrms.company.com
erp.company.com
crm.company.com
vpn.company.com
sap.company.com
sqladmin.company.com
payroll.company.com
intranet.company.comWhen you obtain a publicly trusted certificate for these names, the certificate itself can become part of the public Certificate Transparency (CT) ecosystem.
Certificate Transparency exists to make publicly trusted certificate issuance observable.
Consequently, issuing a certificate for:
payroll.company.comcan reveal that this hostname exists, even though the payroll application itself is not reachable from the Internet.
Let's Encrypt community guidance explicitly notes that domain names in issued certificates are publicly visible through Certificate Transparency logs. (Let's Encrypt Community Support)
This creates an important distinction:
The server may be private, but the certificate name may not be private.
For a harmless homelab service, this may not matter.
For a corporate environment, it may.
An internal hostname can reveal information about:
It does not automatically create a vulnerability. But it can provide useful reconnaissance information to someone researching your organization.
This is an easy point to misunderstand.
DNS-01 keeps the server private.
It does not make the certificate private.
The validation process proves to Let's Encrypt that you control the domain.
Once issued, the certificate is a publicly trusted Web PKI certificate.
Anyone who obtains the certificate can inspect its publicly visible subject/SAN information.
So there are actually two separate questions:
Can outsiders reach my internal server?
and
Can outsiders learn the names for which I obtained publicly trusted certificates?
DNS-01 addresses the first question.
It does not necessarily address the second.
When an organization uses Let's Encrypt DNS-01, its certificate issuance depends on proving control of the public domain.
That normally involves the organization's DNS infrastructure or a DNS provider API.
The ACME automation therefore needs the ability to create or manage _acme-challenge records.
Let's Encrypt itself identifies DNS write access as a sensitive asset in DNS-based certificate automation. Its newer DNS-PERSIST-01 documentation specifically discusses the security implications of distributing DNS credentials through issuance and renewal infrastructure. (Let's Encrypt)
This does not mean DNS-01 is inherently unsafe.
It means the organization has introduced another dependency and another credential/control path that needs to be secured.
A compromised DNS API credential can have consequences far beyond one internal web server.
Consider an internal application:
https://hrms.company.comThe application is inside your network.
But its certificate lifecycle may depend on:
Your server → ACME client → DNS provider → Internet → Let's Encrypt
If certificate renewal fails because of:
the internal application can eventually end up with an expired certificate.
That creates an interesting architectural situation:
Your internal HTTPS service may be operationally dependent on external Internet infrastructure.
For organizations that deliberately design internal systems to operate independently of the public Internet, this is worth considering.
A publicly trusted certificate is convenient because devices already trust the public CA hierarchy.
No internal root CA needs to be installed on every workstation.
That is a genuine advantage.
But ask another question:
Does an internal application actually need to be trusted by every device on the Internet?
Usually, no.
If hrms.company.com is intended to be accessed only by employees using company-managed devices, the desired trust model may simply be:
Company-managed devices trust the company's internal CA.
A private CA can issue certificates for internal names, private namespaces and internal IP addresses without making those certificates part of the public Web PKI.
That creates a much smaller trust boundary.
Consider these two situations.
Public website
https://www.company.comThe service is intended for anyone on the Internet.
A publicly trusted certificate makes sense.
Internal application
https://10.20.30.40or
https://hrms.internalThe service is intended only for authorized users and devices inside the organization.
A public Internet trust anchor is not necessarily required.
The security objective is different.
For an internal service, the organization may want:
That is exactly the environment where an internal/private CA can be appropriate.
This area has changed recently.
Historically, Let's Encrypt did not issue certificates for IP addresses. That changed in 2025–2026.
Let's Encrypt now supports publicly trusted IPv4 and IPv6 certificates, but its IP-address certificates must use the short-lived certificate profile and are valid for approximately six days. IP validation uses HTTP-01 or TLS-ALPN-01 — not DNS-01. (Let's Encrypt)
So a modern organization should not make the outdated claim:
"Let's Encrypt cannot issue certificates for IP addresses."
That is no longer correct.
The more useful question is:
Should an internal organization use a publicly trusted, short-lived certificate for an internal IP address when the service is intended only for its own controlled network?
There are still architectural reasons to consider a private CA, particularly where the application needs certificates for numerous private IPs, internal hostnames or infrastructure components and where Internet-independent certificate management is important.
Both technologies solve different problems.
| Requirement | Let's Encrypt + DNS-01 | Private CA |
|---|---|---|
| HTTPS encryption | Yes | Yes |
| Server authentication | Yes | Yes |
| Public browser trust | Yes | No, unless trust is installed |
| Internal-only servers | Possible | Yes |
| Private/internal names | No | Yes |
| Internal IP addresses | Possible with current short-lived IP certificates, but not via DNS-01 | Yes |
| Public CT visibility of issued domain certificates | Yes | No public CT requirement |
| Internet dependency for normal DNS-01 issuance/renewal | Yes | Can be eliminated |
| Central internal trust control | Limited | Yes |
| Suitable for completely isolated networks | Generally no | Yes |
| Requires managed-device trust distribution | Usually no | Yes |
The important point is that public trust and private trust are different design choices.
There are legitimate cases.
For example, you may have:
app.company.comwith:
In that situation, DNS-01 can be a perfectly reasonable solution.
Let's Encrypt itself does not require the actual web server to be publicly reachable when DNS-01 is used. (Let's Encrypt Community Support)
The point is not that DNS-01 is "bad."
The point is that it should be an informed architectural decision.
A private CA becomes particularly interesting when you have many internal services such as:
and the organization wants these certificates to remain part of an internal trust ecosystem.
The organization controls:
That is the fundamental advantage of a private PKI.
Let's Encrypt DNS-01 is a clever way to obtain publicly trusted HTTPS certificates for services that are not publicly reachable.
But that does not automatically make it the best choice for internal applications.
Before using it, ask:
Do I really want a public Certificate Authority issuing publicly trusted certificates for my internal applications?
Then consider:
If the answer to these questions points toward an internally controlled trust model, a private CA may be the more natural architecture for internal HTTPS.
The goal is not simply to make the browser show a padlock.
The goal is to establish confidentiality and authenticated trust without unnecessarily expanding the visibility and dependency of your internal infrastructure.
For organizations that need HTTPS for internal and on-premise applications, SecureNT Intranet SSL is designed specifically for this use case.
It can be used for internal:
The important distinction is simple:
Public websites need public trust. Internal applications can use controlled organizational trust.
Choose the certificate architecture according to the environment you are protecting — not simply because a publicly trusted certificate is easier to deploy.
Copyright © 2026 Secure Network Traffic. All rights reserved. SecureNT is a registered trademark of Secure Network Traffic.