6 ms·

This seems like a perfect use case for wild card certs, especially if you have internal sites on a different (sub) domain from your prod servers. Yes, multiple

This seems like a perfect use case for wild card certs, especially if you have internal sites on a different (sub) domain from your prod servers. Yes, multiple servers have the same private key, but when the alternative is self-signed or no encryption, that is an easy trade off for me.

justusthane 5y ago
I don't know how LE does it, but at least with DigiCert (and I assume other commercial CAs), servers sharing the same wildcard cert don't have to share a private key. You generate a separate CSR from each server, and then request a duplicate copy of the wildcard cert using that CSR. That way they can have different SANs as well.
- zrail 5y ago
  Wildcard certs are (only?) issued from DNS-01 challenges. As long as the requester can satisfy the DNS challenge ACME doesn't care about key uniqueness.
  - Spooky23 5y ago
    With Digicert, you do a different API call “duplicate certificate” to avoid buying another cert unnecessarily. I would consider it to be a best practice to keep unique keys as an SOP as it discourages bad behaviors, like keeping private keys accessible on file servers or even mail.
  - dsr_ 5y ago
    Right. If you control the DNS, you can point names at any IP address and get appropriate certs for them. Therefore, you must protect your DNS infrastructure.
    - Hamuko 5y ago
      Isn't the need to protect your DNS infrastructure pretty obvious anyways even when ignoring certificate validation?
      - rocqua 5y ago
        Besides, if I can change your DNS, I can change your HTTP responses as well. So control over DNS already lets me get a lets-encrypt cert for you anyway. Though it is slightly easier to notice if someone changes your DNS to point to a different server than if someone adds a TXT record. I say slightly because if I change your DNS to point at my server I can just proxy requests to your old server so everything still looks like it works. Heck, even with most other certificate issuers I can get a cert in similar ways when controlling DNS.
        egberts1 5y ago
        How often do one monitor their zone files and its updates? Would you be able to catch new subdomains being created under your watch?
      - fomine3 5y ago
        Obvious, but tend to be missed on small deployments.
- ivanr 5y ago
  When multiple CSRs [and thus multiple private keys] are involved you end up with multiple wildcard certificates. There is no sharing, technically speaking, but obviously the hostnames in all the wildcards are the same. However, that doesn't really buy you much in terms of security as any one of those wildcards can be used in an active network attack against any matching service if compromised. That is, unless you're using some sort of public key pinning, but that's very rare to find today and works only in a custom application or something that supports DNSSEC/DANE.
  - tialaramex 5y ago
    They also say the "duplicate" "wildcards" have different SANs. Their whole narrative makes no technical sense, but presumably the situation is that they've technically got a very limited understanding of what they're doing and the people selling the product have understandably limited enthusiasm for trying to educate suckers who are buying a product. What's the line from Margin Call? Sold to willing buyers at the current fair market price.
    - justusthane 5y ago
      Sorry? I'm not sure why you're calling me a sucker, but the wildcard certificates that we purchase from DigiCert can be reissued as many times as we want using separate CSRs, and, yes, with different SANs. DigiCert calls this a "duplicate", but yes, obviously it is technically a new certificate. What is the problem with that?
      - tialaramex 5y ago
        A wildcard is a name consisting of a single asterisk (matching any label) instead of the first label of a DNS name inside an eTLD+1. [Historically some other wildcards existed but they're prohibited today] But SANs are just names (that's even what it stands for, "Subject Alternative Name" the word alternative is because this is for X.509 which is part of the X.500 directory system, in which names are part of the X.500 hierarchy, while these names are from the Internet's naming systems DNS and IP addresses which could be seen as an alternative to that hierarchy) So in changing both the names, and the keys, you're just getting a completely different certificate, maybe the pricing is different for you than purchasing more certificates, but these certificates aren't in any technical sense related to the other certificate. It's a problem to use nomenclature that's completely wrong in a technical discussion like this. If you call the even numbers "prime" you shouldn't be surprised at the reaction when you claim "half the natural numbers are prime" in a thread about number theory. [Edited to fix eTLD to eTLD+1 obviously we can't have people issuing wildcards directly inside an eTLD]
silvestrov 5y ago
> perfect use case for wild card certs I don't like distributing wild card certs as you then have a bigger problem if the cert is leaked. When the cert is host specific you immediately know where the leak comes from and the scope of the leak is restricted.
- sigjuice 5y ago
  Yes, the scope of the leak would be limited. But if a privkey.pem file from one of the hosts of my network is leaked, how do I “immediately” know which host the leak came from?
  - deleted 5y ago
    [deleted]
dijit 5y ago
Please stop advocating for wildcard certificates. http://blog.dijit.sh/please-stop-advocating-wildcard-certificates http://blog.dijit.sh/please-stop-advocating-wildcard-certifi... http://blog.dijit.sh/follow-up-wildcard-tls-certificates http://blog.dijit.sh/follow-up-wildcard-tls-certificates
- kayodelycaon 5y ago
  Chrome is giving me certificate errors. NET::ERR_CERT_DATE_INVALID
- imadethis 5y ago
  …that’s why I said to have your LAN on a different domain or subdomain, so it can’t be a valid cert for your prod traffic.

justusthane 5y ago

I don't know how LE does it, but at least with DigiCert (and I assume other commercial CAs), servers sharing the same wildcard cert don't have to share a private key. You generate a separate CSR from each server, and then request a duplicate copy of the wildcard cert using that CSR. That way they can have different SANs as well.

zrail 5y ago
Wildcard certs are (only?) issued from DNS-01 challenges. As long as the requester can satisfy the DNS challenge ACME doesn't care about key uniqueness.
- Spooky23 5y ago
  With Digicert, you do a different API call “duplicate certificate” to avoid buying another cert unnecessarily. I would consider it to be a best practice to keep unique keys as an SOP as it discourages bad behaviors, like keeping private keys accessible on file servers or even mail.
- dsr_ 5y ago
  Right. If you control the DNS, you can point names at any IP address and get appropriate certs for them. Therefore, you must protect your DNS infrastructure.
  - Hamuko 5y ago
    Isn't the need to protect your DNS infrastructure pretty obvious anyways even when ignoring certificate validation?
    - rocqua 5y ago
      Besides, if I can change your DNS, I can change your HTTP responses as well. So control over DNS already lets me get a lets-encrypt cert for you anyway. Though it is slightly easier to notice if someone changes your DNS to point to a different server than if someone adds a TXT record. I say slightly because if I change your DNS to point at my server I can just proxy requests to your old server so everything still looks like it works. Heck, even with most other certificate issuers I can get a cert in similar ways when controlling DNS.
      - egberts1 5y ago
        How often do one monitor their zone files and its updates? Would you be able to catch new subdomains being created under your watch?
    - fomine3 5y ago
      Obvious, but tend to be missed on small deployments.
ivanr 5y ago
When multiple CSRs [and thus multiple private keys] are involved you end up with multiple wildcard certificates. There is no sharing, technically speaking, but obviously the hostnames in all the wildcards are the same. However, that doesn't really buy you much in terms of security as any one of those wildcards can be used in an active network attack against any matching service if compromised. That is, unless you're using some sort of public key pinning, but that's very rare to find today and works only in a custom application or something that supports DNSSEC/DANE.
- tialaramex 5y ago
  They also say the "duplicate" "wildcards" have different SANs. Their whole narrative makes no technical sense, but presumably the situation is that they've technically got a very limited understanding of what they're doing and the people selling the product have understandably limited enthusiasm for trying to educate suckers who are buying a product. What's the line from Margin Call? Sold to willing buyers at the current fair market price.
  - justusthane 5y ago
    Sorry? I'm not sure why you're calling me a sucker, but the wildcard certificates that we purchase from DigiCert can be reissued as many times as we want using separate CSRs, and, yes, with different SANs. DigiCert calls this a "duplicate", but yes, obviously it is technically a new certificate. What is the problem with that?
    - tialaramex 5y ago
      A wildcard is a name consisting of a single asterisk (matching any label) instead of the first label of a DNS name inside an eTLD+1. [Historically some other wildcards existed but they're prohibited today] But SANs are just names (that's even what it stands for, "Subject Alternative Name" the word alternative is because this is for X.509 which is part of the X.500 directory system, in which names are part of the X.500 hierarchy, while these names are from the Internet's naming systems DNS and IP addresses which could be seen as an alternative to that hierarchy) So in changing both the names, and the keys, you're just getting a completely different certificate, maybe the pricing is different for you than purchasing more certificates, but these certificates aren't in any technical sense related to the other certificate. It's a problem to use nomenclature that's completely wrong in a technical discussion like this. If you call the even numbers "prime" you shouldn't be surprised at the reaction when you claim "half the natural numbers are prime" in a thread about number theory. [Edited to fix eTLD to eTLD+1 obviously we can't have people issuing wildcards directly inside an eTLD]

silvestrov 5y ago

> perfect use case for wild card certs I don't like distributing wild card certs as you then have a bigger problem if the cert is leaked. When the cert is host specific you immediately know where the leak comes from and the scope of the leak is restricted.

sigjuice 5y ago
Yes, the scope of the leak would be limited. But if a privkey.pem file from one of the hosts of my network is leaked, how do I “immediately” know which host the leak came from?
- deleted 5y ago
  [deleted]

dijit 5y ago

Please stop advocating for wildcard certificates. http://blog.dijit.sh/please-stop-advocating-wildcard-certificates http://blog.dijit.sh/please-stop-advocating-wildcard-certifi... http://blog.dijit.sh/follow-up-wildcard-tls-certificates http://blog.dijit.sh/follow-up-wildcard-tls-certificates

kayodelycaon 5y ago
Chrome is giving me certificate errors. NET::ERR_CERT_DATE_INVALID
imadethis 5y ago
…that’s why I said to have your LAN on a different domain or subdomain, so it can’t be a valid cert for your prod traffic.