FAQs
Those might have popped-up in your mind.
Categories
Do you issue Intranet SSL for internal names with regular TLDs ?
We issue Intranet SSL to all internal names, whether they use any regular TLD or not.
Some Private Certifying Authorities do not issue Intranet SSL if your internal domain name uses a regularly used Top Level Domain (TLD) name, including ccTLD reserved for countries.
For example, if your internal domain name is name1.com or name2.net, or name3.us then they won’t issue Intranet SSL Certificate to you. They will insist that you buy their regular SSL Certificate issued by a public CA.
Tagged In
No Comments Yet.
Why use an Intranet SSL on Internal Network Servers ?
CA/Browser Forum (CA/B), the regulatory body that governs the SSL industry, does not allow Public CAs to issue Public SSL Certificates to Private Internal Networks covered under IETF RFC 1918.
So, internal/private Servers have to use SSL Certificates from non-public CAs or Self-Signed Certificates.
Of course, some of these Public CAs do issue Intranet/non-Public SSL Certificates using non-Public Root Certificates. SecureNT Intranet SSL does the same but offers it quickly and at a much more attractive price.
No Comments Yet.
Why do I need to install the CA cert on the client desktops also ?
It’s a good question. If public CA could issue SSL certificates for internal names like local hosts, IP addresses, or server names then we - Private Certifying Authority (CA) - won’t exist.
We issue SSL certificates to local hosts, server names, IP addresses and internal URLs. They are SSL certificates for internal network names. And our CA certificates are not trusted by the browsers and the client Operating Systems like Windows.
Reason for this situation is that CA/browser Forum which governs Public Certifying Authorities (CA) decided in 2015 that public CA can’t issue SSL certificates to Internal Names and internal IP addresses. See this file for details.
Hence Public CAs like Let’s Encrypt, DigiCert, GlobalSign, EnTrust etc. can’t issue SSL certificates for internal networks.
So, who so ever issues SSL for Internal Names or internal IP addresses have to issue them with non-public/Private CA roots only.
When you use such SSL certificates Operating System vendors and browsers don’t trust them because of CA Browser Forum’s policy. So, for browser to trust them customer needs to install Private CA roots on to each client device.
- It's simple and takes hardly 10-15 seconds to install.
- It has to be done once only.
- If you have many devices then you can use Microsoft Group Policy to install on all connected devices in a few minutes.
- No matter who supplies your Intranet SSL, this technical requirement will always be there.
- All our customers do it because it gives them peace of mind.
It’s super easy to install using Microsoft Group Policy. See our blog page for details.
Our customers use SecureNT Intranet SSL certificates for internal web application like ERP, Email, HRMS, CRM, Service Desk, Analytics, etc and so on. These are very critical applications for their business. So, due to our certificates important flowing on the internal networks is encrypted. And their data is protected from the hackers and employees with wrong intentions.
Tagged In
No Comments Yet.
What Are the Risks of Using Let's Encrypt for Internal Websites ?
Using Let's Encrypt for an internal website is not inherently insecure. However, using a publicly trusted CA for an internal-only application has some considerations:
1. Certificate Transparency: Publicly trusted certificates are logged in Certificate Transparency systems. Internal hostnames such as vpn.company.com or payroll.company.com may therefore become publicly discoverable.
2. External dependencies: DNS-01 certificate issuance and renewal can depend on your DNS provider, DNS API and Internet connectivity.
3. DNS credentials: Automated DNS-01 requires access to DNS infrastructure. Those credentials need to be carefully protected and restricted.
4. Public trust: An internal HRMS or ERP normally needs to be trusted only by authorized company devices. Public CA trust may therefore provide more trust than the application actually requires.
These are architectural considerations, not vulnerabilities in Let's Encrypt itself.
A Private CA provides an alternative in which the organization controls certificate issuance and which devices trust the CA.
In short: The question is not whether Let's Encrypt is secure, but whether public Web PKI is the right trust model for your internal applications.
Related: Let's Encrypt vs Private CA for Internal Websites
Tagged In
No Comments Yet.
Let's Encrypt vs Private CA for Internal Websites ?
The fundamental difference is who establishes trust.
Let's Encrypt is a publicly trusted Certificate Authority. Devices generally trust its certificates without the organization installing an internal CA.
A Private CA is controlled by the organization. Authorized devices are configured to trust the organization's CA.
For internal websites, both can provide HTTPS encryption and server authentication.
| Let's Encrypt | Private CA | |
|---|---|---|
| Public trust | Yes | No |
| Internal hostnames | Limited | Yes |
| Private IP addresses | Subject to current IP-certificate rules | Yes |
| CT visibility | Public certificates are logged | No public CT requirement |
| Internet dependency | Yes for public issuance/validation | Can operate internally |
| Trust control | Public CA ecosystem | Organization controlled |
Let's Encrypt can be a practical choice when automatic public trust and existing public-domain infrastructure are important.
A Private CA can be appropriate when an organization wants controlled trust, internal naming, private IP certificates or greater independence from public infrastructure.
In short: Neither is universally better. The appropriate choice depends on whether the application needs public Web PKI trust or controlled organizational trust.
Related: Can I Use Let's Encrypt for Internal Websites?
Tagged In
No Comments Yet.
Categories
Tags