Boost your internal PKI/Microsoft CA security with FREE green Extended Validation SSL in 15 minutes or close your eyes until 2016!
One of the new CAB Forum baseline requirements is that all SSL certificate issuers are to stop issuing SSL certificates with internal host names and IP addresses. Currently it is possible to get internal host names in public certificates until 2016, but after 1. July it will be shortened to 2015. But keep reading and you will remove this threat today, instead of waiting to 2015-2016.
Normal usage of SSL certificates
Most companies with a medium to large infrastructure, use an internal PKI solution like Microsoft Certification Authority for identity and encryption on internal workstations and accounts. They will also use internal CA to issue certificates for server systems that are only accessed by internal computers where Root CA trust can be controlled automatically thru GPO or similar.
But external facing websites and server systems use public external CA issued SSL certificates, to ensure trust by all units including mobile units and external computers.
(did you see the padlock in the above image?)
Example of attack
It makes sense to prevent easy attacks on the identity part of SSL security for internal systems. Any internal website would be easy to replace with a fake site or do a man in the middle attack with a real external publically trusted SSL certificate that includes the internal host names. Example: an internal password management portal on https://mypassword.abc-organization.local. The intruder gets a certificate issued to www.notyours.dk including a SAN name “mypassword.abc-organization.local”. It would be easy for the intruder to setup a fake website to harvest passwords with a real SSL certificate that all clients would trust equally to their internally issued SSL certificate on the existing system. Clients would see the padlock with no visible changes.
What makes this attack possible
Because clients and browsers traditionally only showed GOOD/BAD with a gold padlock or a warning message, users have learned that if there is a “https” and a padlock everything is fine and no need to worry. But the certificate is not only about being trusted and encryption, it is also about identity validation, users just didn’t pay attention to this because it wasn’t clearly visible to them.
I have never seen a normal user click on a padlock and examine what certificate is on a server, but that might just be me.
In comes Extended Validation EV Green SSL, your knight in green armor!
Extended Validation (EV) SSL certificates were introduced to give that extra level, with a clear green address bar as indicator to users that the certificate is “better”. I write “better” because again the user’s don’t realy know what the difference is, but now at least they can see a difference between an automated domain validated SSL certificate and the EV manually validated certificate.
My suggestion to improve internal security and prevent internal host names attack
Teach your internal users that all web systems internally must have a green address bar to be safe, if the green address bar is not there, they should not use the system. An intruder is not able to issue a trusted EV certificate with internal host names and IP addresses, as they are not allowed in publically issued EV certificates. This effectively makes it a lot harder for the intruder to create a certificate with trust that can replace yours with EV green address bar.
And best of all internally issued SSL certificates with EV green address bar is free, doesn’t cost more than your time to configure things that you would configure anyways.
My SSL setup would look like this
- External server systems like OWA/RDP/Citrix/etc. where full control of clients is not possible.Use external CA issued certificates from a trusted issuer like GlobalSign, Symantec (VeriSign), GeoTrust or Entrust. For consistency in your security policy (use only systems with green address bar) it would of course be simpler if these certificates are EV certificates.
- Internal server systems like Intranet/Management/Other, where full control of clients is possible.
Use internal PKI like Microsoft CA to issue internal certificates from a custom template restricted to server/security administrators, with EV enabled identifier.
- Internal workstations, user accounts and servers not using client visible certificates, where full control of clients is possible.
Use internal PKI like Microsoft CA, with standard template and if wanted auto enrollment.
- Use GPO to ensure trust to your internal issuing CA and add EV functionality to the root CA and its intermediate issuing CAs in internal clients.
- Inform users where they should expect the green address bar and how they should react if it isn’t there.
Technical how to
I was inspired by the Microsoft Directory Services Team blog post "Extended validation support for websites using internal certificates". I see no reason to create a new full technical guide as theirs works just fine, so go ahead and check it out.
The quick 1-2-3 version.
- Edit a certificate template, add an issuance policy with a new unique OID of your choosing.
- Add the CA certificate issuing certificates for the new template to client machines, preferably with a GPO and edit its extension, add your OID from before and mark it as an EV policy.
- Secure the template and start issuing certificates for your servers.
Here are my comments/tips to get the guide working faster for your testing/trials.
- Create a 2008 template, i.e. copy “Webserver 2008” and rename to “Webserver EV SSL”.
Make sure you edit security and restrict who can enroll/issue this template.
- When adding the issuance policy, any URL will do including your own company website. In production with a larger company you would of course create a CPS.
A random Object ID will automatically be generated for you, so don’t worry about that.
- Don’t forget to enable the template.
- When issuing your new flashy EV certificates, ensure you add at least these elements to the certificate as they show up in the browser address bar, and look weird when empty: Common Name, Organization, and Country.
- When creating the GPO make sure to use same Object ID (OID).
Also make sure to add both root and the issuing intermediate CA you will use for the EV SSL.
All parts of the chain must have the ability to issue with your EV OID or “all policies”.
Do not forget the most important part in all of this, is to educate your users to look for the green address bar! Or it will just become another padlock thingy that usually is there 😛