3 ms·

I understand what your saying but, I don't think I can just make this work out of the box with a Tom cat install? Don't I still need another Daemon/batch proce

I understand what your saying but, I don't think I can just make this work out of the box with a Tom cat install? Don't I still need another Daemon/batch process? My issues are much less IIS cert update and center around how I need to prove site/domain ownership. Especially for a wild card. To me the documentation looks the same( windows or linux) a periodic update to my dns txt record to show I control this/these sites. Which means my server has to have write access to my dns?

tialaramex 7y ago
IF you want a wildcard then yes Let's Encrypt only offers that for DNS proof of control. You can do two tricks here which let you greatly reduce the scope of the power granted to a machine getting the certificate and then avoid that machine having to be the machine which wants the certificate. 1. Use CNAME to make different DNS server hierarchy own the ACME proof of control. A CNAME DNS record can be permanently added to your real site, telling Let's Encrypt that it should ask DNS for a different name instead, and only that name needs to be writeable by the periodic renewal process. You can use this to pass DNS challenges for a domain where actual DNS changes take six weeks and a dozen people's signatures, because you only need one change once, not once per renewal. You should find documentation explaining this, or you can ask Let's Encrypt's community site to help if you explain your specific situation. 2. CSR re-use. Certificate Signing Requests don't have timestamps inside them. By default Let's Encrypt's popular Certbot client mints brand new key pairs for every renewal and so it needs fresh CSRs, but you needn't do that. Mint keys once when a server is created, produce a CSR for the certificate you'll want, and then re-use that CSR in a machine which just does the renewal periodically, the actual servers can fetch their renewed certificate from that machine or wherever, the certificate is public so it doesn't matter and the keys haven't changed they just need the renewed certificate for the same keys.
- PretzelFisch 7y ago
  Thanks for the reply. I had a strong feeling the tool was causing an issue and not handling case 2 properly( or with enough configuration options).

tialaramex 7y ago

IF you want a wildcard then yes Let's Encrypt only offers that for DNS proof of control. You can do two tricks here which let you greatly reduce the scope of the power granted to a machine getting the certificate and then avoid that machine having to be the machine which wants the certificate. 1. Use CNAME to make different DNS server hierarchy own the ACME proof of control. A CNAME DNS record can be permanently added to your real site, telling Let's Encrypt that it should ask DNS for a different name instead, and only that name needs to be writeable by the periodic renewal process. You can use this to pass DNS challenges for a domain where actual DNS changes take six weeks and a dozen people's signatures, because you only need one change once, not once per renewal. You should find documentation explaining this, or you can ask Let's Encrypt's community site to help if you explain your specific situation. 2. CSR re-use. Certificate Signing Requests don't have timestamps inside them. By default Let's Encrypt's popular Certbot client mints brand new key pairs for every renewal and so it needs fresh CSRs, but you needn't do that. Mint keys once when a server is created, produce a CSR for the certificate you'll want, and then re-use that CSR in a machine which just does the renewal periodically, the actual servers can fetch their renewed certificate from that machine or wherever, the certificate is public so it doesn't matter and the keys haven't changed they just need the renewed certificate for the same keys.

PretzelFisch 7y ago
Thanks for the reply. I had a strong feeling the tool was causing an issue and not handling case 2 properly( or with enough configuration options).