Steve Young - Fotolia
Is it possible to create a public key infrastructure that can bypass certificate authority baseline requirements and browser certificate policies? Is there server software that can bypass the policies and requirements?
Without knowing why such a requirement exists, it's difficult to offer advice other than these policies and requirements exist for a reason, and any network relying on a noncompliant public key infrastructure (PKI) is at risk for man-in-the-middle attacks, snooping and worse.
Enterprises have long used self-signed certificates, or set up private certification authorities to authenticate and secure internal servers, applications and IP addresses that do not require public trust, yet need the security provided by SSL encryption. However, in such situations, it's important to use appropriate, dedicated hardware and software to provide the necessary level of security.
Due to the seriousness of attacks abusing incorrectly installed or incorrectly issued certificates, the CA/Browser Forum, which manages the baseline requirements for the issuance and management of publicly trusted certificates, and sets the industry standard for the use of SSL certificates, introduced stricter checks and controls on public certificate authorities and the types of certificates they can issue.
For example, since 2015, the CA/Browser Forum no longer allows publicly trusted SSL certificates to include local names, such as internal server names and reserved IP addresses. Likewise, it's no longer possible to purchase a validated SSL certificate for mail or wiki domain names for internal use. This is why many companies run their own private certificate authorities and use self-signed certificates; it reduces costs and enables the use of domain names like mail, wiki and test.
Microsoft Windows Server and other server operating systems provide the ability to operate a private certificate authority. Other third-party solutions also exist, like Symantec's Private Certification Authority and GlobalSign's IntranetSSL, which issues certificates using GlobalSign nonpublic CAs.
Because these certificates are issued from nonpublicly trusted root certificates -- roots that are not distributed by the major browser and operating system vendors -- the certificates are not constrained by the CA/Browser Forum baseline requirements.
However, to prevent internal users' browsers from flagging these certificates as untrusted, it's necessary to push out the nonpublic root certificates to users via Group Policy Object or another centralized management system. This enables network administrators to configure internal browsers to accept certificates issued by the private certificate authority, although they still won't be trusted outside the network environment. Any public-facing servers used in production environments have to use certificates issued by root certificate authorities that are trusted by all the major operating systems.
Even though administrators don't have to maintain the same stringent controls over their in-house certificate keys and infrastructure as a public certificate authority, weak security practices can compromise the entire PKI and create a situation where no internal certificates can be trusted.
Before committing to running a private certificate authority, take the time to understand the pros and cons of running an internal PKI, and ensure that the IT department has the in-house skills and resources to manage it effectively and securely.
Learn how PKI problems can complicate VPN management
Read more about the differences between public and private CAs
Find out about different CA management products
Dig Deeper on PKI and digital certificates
Related Q&A from Michael Cobb
WhatsApp vulnerabilities can enable hackers to bypass end-to-end encryption and spoof messages. Expert Michael Cobb explains how these attacks work ... Continue Reading
Disabling Google location tracking involves more than turning off Location History. Learn how to manage your account settings to stop tracking ... Continue Reading
Compared to TLS 1.2, TLS 1.3 saw improvements in security, performance and privacy. Learn how TLS 1.3 eliminated vulnerabilities using cryptographic ... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.