2

I currently have a valid wildcard certificate installed on OS X 10.8.2 server. To make sure we know what I'm talking about the cert is *.domain.com (example only) I'd love to use this to secure as much of everything as I can.

Can I use this certificate to generate certificates for computer1.domain.com, computer2.domain.com, (subdomains inside MY domain) etc... ? Or do I just install the wildcard cert everywhere?

I do have the ability in Keychain Access under Certificate Assistant to create a Certificate Authority.

I can create code signing certs using Certificate assistant as well.

I'd also like to be able to create Digital signatures for mail.domain.com based on the Wildcard SSL.

Is any of this possible? My goal is to have everything be legitimate and above board.

Are there any questions I can answer to help clarify anything I've stated?

lynks
  • 10,636
  • 5
  • 29
  • 54
Everett
  • 1,506
  • 1
  • 12
  • 20

3 Answers3

7

A certificate is only as good as whoever validates it thinks it is. A certificate is good for SSL as long as the SSL clients (e.g. Web browsers, or VPN clients) accept it as good. Whatever you do, the existing clients will lead the dance.

A "wildcard" certificate is described in RFC 2818, 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.

This is the only place where the "*" character has any special meaning. This means that your wildcard certificate is "a wildcard certificate" only in the context of a HTTPS server: in that context, the client will require that the intended server name (the one in the URL) matches the name in the certificate; the "wildcard" is a kind of match-all. So your certificate will be accepted by clients as a certificate for servers foo.domain.com, bar.domain.com, qux.domain.com... and so on.

Note that a few other protocols have more or less adopted the same name matching rules; e.g. a certificate for an IMAPS server will also need to contain the server name (that is, the name that the clients expect). Also, note that complete support for wildcards is kind of a rarity (clients who accept to consider *fo*.domain.com as matching foo.domain.com are not legion).

This is completely orthogonal to the question of issuing sub-certificates. A certificate which is accepted as an issuer for other certificate is called a CA certificate and the hallmark of a CA certificate is that it contains a Basic Constraints extension with the cA flag set to TRUE (see RFC 5280, section 4.2.1.9). No client will accept a certificate issued by your "wildcard" certificate unless it has this flag; and the presence or absence of a "*" character in the name is totally irrelevant here.

As a side note, I find a bit dubious the idea of "securing everything" by copying the same certificate and private key in many machines. The more you copy a private key, the less secret it becomes. Asymmetric cryptography was meant as a way to avoid copying secret keys. The normal certificate paradigm is that each entity in a network should have its own private key, instead of sharing the same private key between hosts.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
6

Your certificate will have certain properties, I believe they are called 'certificate usage' or similar. If, under there, you find Certificate Signing, then yes - you can use your certificate to sign other certificates.

Note: the constraint Signing alone does not mean you can sign other certificates, it must be the full Certificate Signing.

Your wildcard certificate is valid for all domains that match *.domain.com, so yes you can use your certificate for https on any subdomains, and it will be accepted by client browsers - assuming of course that your certificate is signed by a trusted CA.

Extra Note:

A pretty easy way to tell is by how much you paid for this certificate. A Certificate Signing certificate signed by a trusted and ubiquitous CA is worth a very large amount of money.

lynks
  • 10,636
  • 5
  • 29
  • 54
  • Is there any place you can recommend that offers a wildcard with Cert Signing? Google has NOT been my friend with this. – Everett Dec 06 '12 at 19:55
  • I'm afraid I think that's going to be hard to find, plus I believe they cost hundreds of thousands of dollars... – lynks Dec 06 '12 at 20:48
  • I was good with hundreds, not so much with thousands... Thanks. – Everett Dec 07 '12 at 00:42
1

I would be very surprised if you ever got a valid certificate that did both. Certificate signing certs tend to only do that, not support server identification (e.g, SSL), given how much they really need to be protected.

If that certificate and private key were installed on a web server, all an attacker would have to do is breach that web server, and they now have a trusted CA signing key. With that signing key they could then generate a valid certificate for any domain on the internet. Hence why they need to be protected.

Steve
  • 15,155
  • 3
  • 37
  • 66
  • I CLAIM to be an information security professional. I say claim, because I hadn't considered that... My use is a bit if a special case though. I wanted to be able to use this at home. I have an OS X server that I VPN back to (using the wildcard cert I think). So here's my question. Since I already have the SSL cert, I'm assuming making a different cert for the signing function is adequate to protect my home systems (set up the server as an intermediate cert auth, etc). Any other input? I appreciate it all... – Everett Dec 07 '12 at 00:42