How I do to create a wildcard certificate for ALL domains?

Here is my error:

alt text

CACERTIFICATE.crt is imported as trusted in my browser. SERVERCERTICIATE.crt and SERVERPRIVATEKEY.key is used in a proxy server which scans SSL traffic for virus.

The problem is that I in IE has to uncheck: "Tools - Internet Options - Advanced - Warn if adresses in certificates does not match*"

for it to not complain about the certificate. (In the picture eicarcert.PNG I have the setting unchecked, and you see that the cert is trusted).

In firefox (latest), I have to click "Add a security exception" for EVERY SSL-site im visiting. Its pretty irritating to have to "Add a security exception" for every SSL site im visiting even if the certificate is trusted. The firefox pushed out a update to ther SSL handling disallowing * to cover . in domains. Even having a certificate like *.*.* does not makes the browser trust it.

Is it any way to create a certificate valid for ALL domains over the whole globe?

  • 4
    Dude, Take your Certs down. ESPECIALLY the .key files. Those are your private keys. In fact now that you have posted them on the web, you need to revoke them and re-issue them. – Zypher Aug 20 '10 at 21:42
  • In real terms, how does a certificate that is valid for every web site differ from not using a certificate at all? When the key is left in the front door for all to see it doesn't matter whether that door is locked or not. – John Gardeniers Aug 26 '10 at 5:09
  • I understand your comment. But here, the certificate is not meant to provide any security, but to make the browser happy. I have a solution like this: [Client] --A-- [Antivirus Proxy] --B-- [SSL Site] The SSL cert I have maked does only apply for connection A, which means this connection actually does not need any security. The only reason to provide SSL is to make the browser, and any javascript at internet bank sites happy. – sebastian nielsen Aug 30 '10 at 9:26
  • A certificate that is valid for every web site simply delegates the trust decision to the party holding the key corresponding to that certificate. It's not akin to leaving the door open for everyone but it is akin to leaving the door open such that only one person can walk through it. – David Schwartz Aug 28 '11 at 10:40

Unfortunately there has never been a good RFC on how wildcard matching works so the different implementations (SChannel and NSS mainly) are slightly different. However, here's the draft standard which will pin this down:


And here's Microsoft's take on it:


Basically, a wildcard may appear as the left-most label and it matches exactly one label. So *.example.com matches www.example.com, but not example.com (because that would mean matching zero labels).

'*' matches only 'com', 'org' etc. '*.*' is invalid.

So you can't do what you're trying to do. SSL MITM boxes have to install a root CA onto client machines and then generate certificates on the fly (with caching) for the domains that they want to intercept.

MITM also happen to be a terrible idea which impose huge costs on the rest of the world and break things constantly. Don't expect Chrome to work with them.


You need a multiple domain certificate not a wildcard certificate.

  • Zypher: I know about multiple domain certificate. What I have tried, is issuing a MDC with a subjectaltname list of:<br> SubjectAltName = DNS:*<br> SubjectAltName = DNS:*.*<br> SubjectAltName = DNS:*.*.*<br> SubjectAltName = DNS:*.*.*.*<br> SubjectAltName = DNS:*.*.*.*.* and so on.<br> Doesn't work. Have also tried:<br> subjectAltName = DNS:*a<br> subjectAltName = DNS:*b<br> ...<br> subjectAltName = DNS:*y<br> subjectAltName = DNS:*z<br> But doesnt work. I own the CA root so I can add/remove/change any extensions on both CA and server certiciate. Any ideas? – sebastian nielsen Aug 20 '10 at 21:53
  • I'm pretty sure you can't just do ..*.*.* you need to have the actual domain, i.e. domain1.com and sub.domain2.com etc. If you think about it allowing you to generate a ..*.* certificate would pretty much destroy the usability of SSL since anyone can say they are anyone at that point – Zypher Aug 20 '10 at 21:55
  • I have a valid CA so still, the certificate would need to be trusted by a CA for the browser to accept it. So allowing a certificate for * should not destroy the useability of SSL as long as no "real" CAs sign a certificate for . I have a own CA which are imported in my own browser (The CACERTIFICATE and CAPRIVATEKEY files is my CA which is imported in my browser). I would want to sign * with my own CA and get it trusted in my browser without having to uncheck "Warn if adresses in certificate does not match". I think theres some extension allowing this. – sebastian nielsen Aug 20 '10 at 22:07
  • still you need a Certificated issued by the CA with wildcard support, such as geotrust.com/ssl/wildcard-ssl-certificates – Prix Aug 21 '10 at 0:48
  • You don't simply understand what this should be used to. Its a central antivirus scanning engine. Thats why I need a wildcard certificate valid for all sites over the whole world, for it to be able to hook into SSL traffic and scan it for viruses. I have a own CA and have wildcard support in my certificates. The CA is imported in my browser as trusted, so trust is no problem. What the problem is, is making the certificate valid for *any* domain. – sebastian nielsen Aug 21 '10 at 10:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.