Back in March, a trusted Root Certification Authority (CA), Comodo, accidentally issued nine fraudulent digital certificates for some very popular domains. Unfortunately, the past has repeated itself, this time with a CA called DigiNotar.
If you’ve followed security news over the last few weeks, you’ve likely heard that a Dutch CA called DigiNotar has mistakenly issued over 200 fraudulent certificates to Iran (the certs were for Google, Mozilla, Yahoo, and Tor domains). DigiNotar claims the false certificates issuance was due to an intrusion into their CA infrastructure, and they claim to have since revoked the false certificates. However, experts have learned that DigiNotar issued many more fraudulent certificates than they first admitted.
As mentioned in our Comodo post, when you visit sites, digital certificates help ensure that the site you visit really is the one you think it is. Phishers often try to spoof popular sites in order to steal your credentials. Digital signatures can help prevent this by informing you when a site has an improper certificate, which doesn’t match the domain. However, these falsely issued certificates can allow attackers to leverage them to either create very convincing spoofed sites for the affected domains, or to help them carry out Man-in-the-Middle (MitM) attacks, even when valid certificates are required.
Though DigiNotar claims to have revoked the fraudulent certificates, OS vendors have released patches that either ensure these certificates are revoked, or removes DigiNotar from the list of trusted root CAs. Depending on your OS, I recommend you install the corresponding updates below, to protect yourself from these false certs:
Also, if your web browser supports Online Certificate Status Protocol (OCSP), you can enable it so your browser protects you from sites leveraging these false certificates.
Finally, if you use on of WatchGuard’s appliances, you can also enable OCSP in our HTTP-proxy. Simply enable the setting, “Use OCSP to confirm the validity of certificates.” Our appliances also trust the same root authorities that most web browsers do; so we include DigiNotar in our list of trusted CAs. If you do not want to trust DigiNotar any longer (despite them revoking the false certs), go to Firebox System Manager and click View => Certificates. Then delete the DigiNotar certificate from your trusted list.
If you follow these workarounds, the fraudulent DigiNotar certificates shouldn’t affect you or your network.
For more information about this issue, see the resources below:
- Initial Story (links from Slashdot)
- DigiNotar’s response
- 200 Certs leaked
- Moxie Marlinspike’s proposed solution to such fraudulent digital certs
– Corey Nachreiner, CISSP (@SecAdept)
It’s a Dutch CA not Danish.
Netherlands -> Dutch
Denmark -> Danish
DigiNotar is a dutch and not a Danish CA.
Thanks for the correction… typo by me. Corrected in the online versions. If you refresh, you should see it.
Cheers,
If digital certificates are so important, why does Internet Explorter reject the one from my watchguard UI as:
The security certificate presented by this website was not issued by a trusted certificate authority.
The security certificate presented by this website was issued for a different website’s address.
Good question, and one that I, or someone at WatchGuard support, might need more information to answer. I do not get such a message when I visit our site (from here at work, or from at home). Our certificates are up to date as far as I can see. There could be many reasons for such an issue (including having some SSL decryption device that is not configured properly. Our HTTPS-proxy is one such example.)
But again, the current site cert (https://www.watchguard.com) looks fine to me. Below is a link to a screenshot of me displaying our cert info:
http://i.imgur.com/2DuZw.jpg
Cheers
Oh, I think I misinterpreted your question.. You were asking about the Cert for our Web management UI.
This is very common among all web managed devices. We have to send the device to you with a “self-signed” cert, because we are not a root CA (like verisign etc). Without being a root CA ourselves, there is no cert we can ship on our appliance that your browser will automatically trust. You have to use our certificate management to sort it out… You have a few options:
1) you can just take the cert that is on their, and trust it.
2) if you have your own PKI infrastructure, you can generate your own certificate for our appliance, sign it as trusted, import it (you can add certs to our appliance), and then use it for the Web management.
3) You can buy a cert from a root CA, and import it as well.
So in short, it is normal for most appliances that have SSL managed web interfaces to ship with self-signed certs, that you browser will warn about… However, that is why we provide certificate management capabilities, you can import a trusted cert and use it if you like.
Cheers
This is really interesting, You’re an excessively skilled blogger.
I have joined your feed and look forward to looking
for more of your wonderful post. Additionally, I’ve
shared your site in my social networks
nasa, , harold hill kdeafdkgbgkk