5 ms·

Also, many CA don’t provide programmatic way to order and to download cert. Another annoying manual step, especially consider having multi-domains not convered

Also, many CA don’t provide programmatic way to order and to download cert. Another annoying manual step, especially consider having multi-domains not convered under a single wildcard. Sadly let’s encrypt does not support wildcard... and support for intranet is controversial to thosr who want to keep their intranet “totally private”. I love the autobot. One command to generate new cert, another command to reload my Nginx.

JetSpiegel 9y ago
Let's Encrypt will support wildcards in January 2018.
- CaliforniaKarl 9y ago
  The issue we've run into with Let's Encrypt, is that they have a limit on the number of new (non-renewal) certs in a time period, grouped by high-level domain. So, for example, when you have lots of separate groups running sites until a common domain (groupa.example.com, groupb.example.com), you often hit the new-issuance limit, and have to wait. So, I expect existing CAs (and groups like InCommon) will continue to be around to serve large entities.
  - majewsky 9y ago
    Wildcard certs should help with that. Also, the limit is only on certs, not on domains. If your process allows for issuing a single cert for 100 domains, that also solves the problem. (There is a limit on SANs per cert AFAIK, but I don't have the exact number.)
    - viraptor 9y ago
      If you're dealing with a large scale deployment that involves many endpoints (and not just subdomain-per-user scenario), there are good reasons not to use a wildcard. Other CAs will definitely stay in business there.
      - gregmac 9y ago
        > there are good reasons not to use a wildcard. Such as?
        viraptor 9y ago
        Example: Imagine Microsoft giving anyone "(wildcard).microsoft.com" just because they have a lot of services to deploy and don't want to deal with separate certs. Now, breaking into that service means you can mitm windows updates for anyone and they can't tell a difference. You want to limit the exposure of your certificates, you don't want 50+ teams to share credentials/certs (they're effectively public at that point), and you want to make sure that if you need to revoke the certificate right now, you know you're impacting as few endpoints as possible.
        ivanr 9y ago
        To add to this, there's potentially a similar security problem if you have a bunch of systems with different certificates sharing the same TLS session caching backend or session ticket keys. It doesn't allow any one system to impersonate another, but they can perform active and passive network (MITM) attacks. For server-side caching, some systems now take into account SNI hostname and use it to prevent contamination. If you're in this situation, it's worth looking into how exactly your backend works.
        lucaspiller 9y ago
        It is possible to get a certificate that allows to sign other certificates on your domain? For example you call Verisign and they issue a cert for *.mycompany.com, then you use that to sign another certificate for accounting.mycompany.com?
        viraptor 9y ago
        Yes and no. If your company is worth a few million dollars, can get high enough insurance, can get FIPS certified, and can jump through enough hoops, then yes - you can get an intermediate certificate. That product is not even openly advertised by most CAs. If you're just a "normal company", no, you won't get one. https://translate.googleusercontent.com/translate_c?depth=1&nv=1&rurl=translate.google.com.au&sl=auto&sp=nmt4&tl=en&u=https://www.geotrust.com/de/enterprise-ssl-certificates/georoot/&usg=ALkJrhjsNcK-HRUEkR4Z8w32xMoO7g19EA https://translate.googleusercontent.com/translate_c?depth=1&... The big problem here is that the intermediate CA isn't really limited on what they can grant. You can issue a valid "google.com" cert just as well as "foo.yourcompany.com". The are x509 extensions for limiting the scope in this case, but I don't believe they're widely used or validated at the moment.
  - mrkurt 9y ago
    I don't know how helpful we can be, but we (and other companies like ours) have much higher Let's Encrypt limits. If it'd make your life better send me an email and we'll help you out.
- apple4ever 9y ago
  Finally! Now they just need to add support for specifying cert length from 10-360 days.
  - kuschku 9y ago
    They won’t ever offer > 90 days, but certificate lengths of about a day would certainly be interesting. I’d certainly switch to 24h valid certificates as soon as possible. Ideally even separate certs for every subdomain, but as Let’s Encrypt has cert limits, and I want to avoid SNI in the future, I’ll probably have to use wildcard certs.
    - icebraining 9y ago
      Curious, why do you want to avoid SNI?
      - deleted 9y ago
        [deleted]
      - kuschku 9y ago
        Basically, I am against SNIs today's implementation, and want to allow people who disable it to visit my sites. SNI transmits the host unencrypted, that is a real security issue.
        jsmthrowaway 9y ago
        In what sense? An attacker can already see the endpoints of a TLS conversation, and worrying about hostname disclosure is security through obscurity; the client already divulged the destination hostname with a probably-cleartext DNS query, too. Not worth worrying about. SNI is fine. If hostname disclosure is a security threat, the system needs rearchitecture. Systems that hostname their customers (mycompany.example.com) should use wildcards for that scenario instead of SNI, among other reasons. That’s the only possible concern I can imagine.
        9y ago
pilsetnieks 9y ago
> One command to generate new cert, another command to reload my Nginx. Maybe this is what you meant but you can do it in a single command. For example: certbot renew --post-hook "service nginx reload"
- merb 9y ago
  that works fine, until it doesn't... multiple servers

JetSpiegel 9y ago

Let's Encrypt will support wildcards in January 2018.

CaliforniaKarl 9y ago
The issue we've run into with Let's Encrypt, is that they have a limit on the number of new (non-renewal) certs in a time period, grouped by high-level domain. So, for example, when you have lots of separate groups running sites until a common domain (groupa.example.com, groupb.example.com), you often hit the new-issuance limit, and have to wait. So, I expect existing CAs (and groups like InCommon) will continue to be around to serve large entities.
- majewsky 9y ago
  Wildcard certs should help with that. Also, the limit is only on certs, not on domains. If your process allows for issuing a single cert for 100 domains, that also solves the problem. (There is a limit on SANs per cert AFAIK, but I don't have the exact number.)
  - viraptor 9y ago
    If you're dealing with a large scale deployment that involves many endpoints (and not just subdomain-per-user scenario), there are good reasons not to use a wildcard. Other CAs will definitely stay in business there.
    - gregmac 9y ago
      > there are good reasons not to use a wildcard. Such as?
      - viraptor 9y ago
        Example: Imagine Microsoft giving anyone "(wildcard).microsoft.com" just because they have a lot of services to deploy and don't want to deal with separate certs. Now, breaking into that service means you can mitm windows updates for anyone and they can't tell a difference. You want to limit the exposure of your certificates, you don't want 50+ teams to share credentials/certs (they're effectively public at that point), and you want to make sure that if you need to revoke the certificate right now, you know you're impacting as few endpoints as possible.
        ivanr 9y ago
        To add to this, there's potentially a similar security problem if you have a bunch of systems with different certificates sharing the same TLS session caching backend or session ticket keys. It doesn't allow any one system to impersonate another, but they can perform active and passive network (MITM) attacks. For server-side caching, some systems now take into account SNI hostname and use it to prevent contamination. If you're in this situation, it's worth looking into how exactly your backend works.
        lucaspiller 9y ago
        It is possible to get a certificate that allows to sign other certificates on your domain? For example you call Verisign and they issue a cert for *.mycompany.com, then you use that to sign another certificate for accounting.mycompany.com?
        viraptor 9y ago
        Yes and no. If your company is worth a few million dollars, can get high enough insurance, can get FIPS certified, and can jump through enough hoops, then yes - you can get an intermediate certificate. That product is not even openly advertised by most CAs. If you're just a "normal company", no, you won't get one. https://translate.googleusercontent.com/translate_c?depth=1&nv=1&rurl=translate.google.com.au&sl=auto&sp=nmt4&tl=en&u=https://www.geotrust.com/de/enterprise-ssl-certificates/georoot/&usg=ALkJrhjsNcK-HRUEkR4Z8w32xMoO7g19EA https://translate.googleusercontent.com/translate_c?depth=1&... The big problem here is that the intermediate CA isn't really limited on what they can grant. You can issue a valid "google.com" cert just as well as "foo.yourcompany.com". The are x509 extensions for limiting the scope in this case, but I don't believe they're widely used or validated at the moment.
- mrkurt 9y ago
  I don't know how helpful we can be, but we (and other companies like ours) have much higher Let's Encrypt limits. If it'd make your life better send me an email and we'll help you out.
apple4ever 9y ago
Finally! Now they just need to add support for specifying cert length from 10-360 days.
- kuschku 9y ago
  They won’t ever offer > 90 days, but certificate lengths of about a day would certainly be interesting. I’d certainly switch to 24h valid certificates as soon as possible. Ideally even separate certs for every subdomain, but as Let’s Encrypt has cert limits, and I want to avoid SNI in the future, I’ll probably have to use wildcard certs.
  - icebraining 9y ago
    Curious, why do you want to avoid SNI?
    - deleted 9y ago
      [deleted]
    - kuschku 9y ago
      Basically, I am against SNIs today's implementation, and want to allow people who disable it to visit my sites. SNI transmits the host unencrypted, that is a real security issue.
      - jsmthrowaway 9y ago
        In what sense? An attacker can already see the endpoints of a TLS conversation, and worrying about hostname disclosure is security through obscurity; the client already divulged the destination hostname with a probably-cleartext DNS query, too. Not worth worrying about. SNI is fine. If hostname disclosure is a security threat, the system needs rearchitecture. Systems that hostname their customers (mycompany.example.com) should use wildcards for that scenario instead of SNI, among other reasons. That’s the only possible concern I can imagine.
        9y ago

pilsetnieks 9y ago

> One command to generate new cert, another command to reload my Nginx. Maybe this is what you meant but you can do it in a single command. For example: certbot renew --post-hook "service nginx reload"

merb 9y ago
that works fine, until it doesn't... multiple servers