Jump to content

Recommended Posts

Posted

Hello, I've created a Extended Validation (EV) Certification Authority (CA) using Active Directory Certificate Authority (AD CS) in Windows Server 2016 Data Center Edition and I've followed the instructions provided here: https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/server-certificate-deployment to install and configure AD CS and this instructions https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd759060(v=ws.11) to configure an EV CA Template and issued an Intermediate Certificate using that template for "server.sgnetworks.net"/"localhost". The EV SSL is working fine in Internet Explorer but not on other browsers. I want to know that:

1.) Why the EV CA is working in IE but not on others?

2.) I know that Chrome, Firefox and other browsers have its own Root Certificate Policies, so can I somehow manage browsers to use my custom EV CA Policy OID? Or can I use one of the OIDs mentioned here: https://en.wikipedia.org/wiki/Extended_Validation_Certificate#Extended_Validation_certificate_identification to issue my own EV CA?

3.) If I somehow manage to issue an EV CA, can I give the Root EV CA to my users to install the Root CA in their browsers to enable EV CA in their browsers?

Posted

You can sign as many certificates as you want using a CA that you control, but those certificates are going to show errors in browsers unless you can convince people to add your CA to their system.

Posted

Yeah, I'm sure that my users will trust my CA. But I want to know that why the CA doesn't show the Green Bar in users when the Green Bar is shown in Internet Explorer.

Posted

Then why it's working on Internet Explorer?

Posted

Is the PC where it's being tested a member of a domain (Specifically the domain that owns the CA)? If so, it works in IE because Windows quietly installs the root for you through AD. IE also is likely most compatible considering it's also made by Microsoft. Firefox will ignore the root as it has its own certificate stores.

 

Chrome should rely on Windows for certificates, like IE does, but knowing google they probably have some odd value that's required, or a bug. EV certs also have a history of not working right in chrome if you google it...

Posted

Yes, the PC is a member of a domain. I the CA is an Enterprise Root CA and I've added a custom policy OID to the Extended Validation tab of the Root CA in Trusted Root Certification Authorities store. And it has worked as expected in IE but not on others (Chrome & Firefox) I've imported the Modified Root CA (which has the OID in the EV tab) in these browser's certificate store and it has worked like a normal CA signed SSL does to enable HTTPS but not showing the fetures of an EV CA like show the Website's Organiztion name in the Address Bar of the browser.

And I want to know that how can I enable the features of an EV CA in Chrome & Firefox, either with custom Policy OID or the OIDs listed here: https://en.wikipedia.org/wiki/Extended_Validation_Certificate#Extended_Validation_certificate_identification.

Posted

Did some research on this, and the long and short of it is...you can't. It's an intentional security measure to prevent malware from installing a root to fake an EV certificate. http://silverskysoft.com/open-stack-xwrpr/2015/09/creating-your-own-ca-that-issues-extended-validation-ssl-certificates/

 

If you really wanted to do this, you'd have to provide a custom-compiled version of Firefox with it added to the white list, and direct your users to not use Chrome. Regular Chrome (though not its parent project Chromium) is closed source, so you'll never get it to work in Chrome short of buying a real certificate.

 

For why it works in IE: 

 

 

IE is different, if you can get to GPO on your CA system, you can set the external OIDs that will allow a green bar. Unfortunately, IE is not a full solution as many people in our org use other browsers.

IE is the only browser out there that allows self-signed/domain-signed EV certs. The domain that owns the CA likely has the above GPO to whitelist the OIDs set by default (or you're using one that's otherwise already allowed in the domain), so EV certs from that domain's CA will green-bar as long as all of the following are met:

  • The certificate is valid.
  • The domain GPO allowing them is applied to the PC.
  • The root certificate is installed.
  • The PC is joined to the same domain as the CA.

Microsoft explicitly allows it to function for certs issued by the domain CA when the PC is joined to the owning domain by default...this was done only because a domain would only exist in a controlled environment, not on random personal devices around the world. These policies are reportedly ignored when the PC is not joined to a domain, preventing malware from abusing them.

Posted

Can I use one of the OIDs listed here: https://en.wikipedia.org/wiki/Extended_Validation_Certificate#Extended_Validation_certificate_identification to issue a root EV CA? As those OIDs are from a well-known CAs and almost every CAs listed there are trusted by every browsers. For example, can I use OID "2.16.840.1.113733.1.7.23.6" (Symantec/VeriSign EV CA) for my root EV CA to issue EV Certificates?

Posted

Nope. To use those OIDs, you'd actually need the CA to issue the certificate. The OIDs are checked against the root that validates the certificate, as well as the list of safe certificates. Faking the OID on the SSL certificate wouldn't help because the root certificate is still the wrong one, and I'd suspect it might just invalidate the certificate entirely.

 

For what it's worth, EV certs have little actual benefit anyway. One of the big reasons they were invented to begin with was to give commercial CAs an excuse to raise prices back to what they were in early-days...exorbitant. The race to the bottom on certificate prices (which finally reached $0 when LE and Comodo came around) was making big name CAs hurt, so they came up with EV high-assurance certs so they could claim to have something better and justify the price hike. Studies have shown they really don't do much better than regular certificates though when it comes to actually preventing credential theft and phishing.

 

I'm sure in a few years time someone will be offering EV certs for cheap or free. Online, fully-automated identity verification is already a big topic these days (especially in areas like the crypto-currency scene), so it would follow that the prices of actually doing the legwork necessary to validate someone requesting one of these will only get cheaper.

Posted

Okay, I understand. But EV Certificates gives a Green Bar which looks so fancy, that's the only reason I wanted to implement it even if it would be localhost.

Thanks for explaining, sir.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...