Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Shouldn't this be a trusted certificate considering it's a wildcard SSL certificate?

That is, shouldn't * cover

Wildcard SSL certificate

share|improve this question
See also this blog post by SE employee Nick Craver, which touches on some related issues involving the implementation of SSL certificates for the SE network. – user1535629 Mar 2 '14 at 9:32
MSIE does not trust it either – kinokijuf Apr 13 '14 at 10:15
up vote 44 down vote accepted

The wildcard replaces only one part of the hostname, e.g. * covers or but not From RFC2818, section 3.1:

...Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., * matches but not f*.com matches but not

share|improve this answer
@ack__: Related info at… – Mechanical snail Feb 28 '14 at 22:52
There is no complete wildcard SSL. The solution in this case would have been to have a certificate with subject alternative names for at least * (exists), (exists) and * (missing). Something like *.* is not allowed. – Steffen Ullrich Feb 28 '14 at 23:05
RFC6125 tries to unify the different handling of certificates among HTTP, LDAP, SMTP etc, but it does not allow *.* or similar. In section 6.4.3 it clearly states that wildcards should only be used within the left-most label (item 1) and that a * should only be compared against the left-most label of the reference identifier (item 2). It explicitely forbids * to match Section 7.2 only acknowledges that not all previous specifications explicitly forbid something like *.*, but neither this RFC nor RFC2818 (HTTPS) allow it. – Steffen Ullrich Mar 1 '14 at 5:13
@SteffenUllrich - "... it does not allow *.* or similar." - Is there any rationale for why this restriction was put in place ? And, does that rationale still apply today ? I don't see any downside in allowing this, other than the lost revenue for SSL Certificate issuers. – Kevin Fegan Mar 5 '14 at 8:28
I don't know the real motivation, but I guess it is to let an organization better reflect it structure and control. You often have a main organisation (like university) with a website and then sub-organisations (like department) which manage their own infrastructure. In this case it would be bad if a compromise of the *.university certificate would make it possible to overwrite all * certificates. – Steffen Ullrich Mar 5 '14 at 16:24

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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