Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

That is, shouldn't *.delaware.gov cover www.corp.delaware.gov?

Wildcard SSL certificate

share|improve this question
1  
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 at 9:32
    
MSIE does not trust it either –  kinokijuf Apr 13 at 10:15

1 Answer 1

up vote 43 down vote accepted

The wildcard replaces only one part of the hostname, e.g. *.delaware.gov covers www.delaware.gov or corp.delaware.gov but not www.corp.delavware.gov. 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., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.

share|improve this answer
    
Correct, but is there a way to create a "complete" wildcard SSL cert then ? –  ack__ Feb 28 at 22:41
2  
@ack__: Related info at security.stackexchange.com/questions/37887/… –  Mechanical snail Feb 28 at 22:52
7  
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 *.delaware.gov (exists), delaware.gov (exists) and *.corp.delaware.gov (missing). Something like *.*.delaware.gov is not allowed. –  Steffen Ullrich Feb 28 at 23:05
1  
RFC6125 tries to unify the different handling of certificates among HTTP, LDAP, SMTP etc, but it does not allow *.*.example.com 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 *.example.com to match bar.foo.example.com. Section 7.2 only acknowledges that not all previous specifications explicitly forbid something like *.*.example.com, but neither this RFC nor RFC2818 (HTTPS) allow it. –  Steffen Ullrich Mar 1 at 5:13
1  
@SteffenUllrich - "... it does not allow *.*.example.com 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 at 8:28

Your Answer

 
discard

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.