6 ms·

Just curious... has anyone so far decided to extend the 3-month certificate expiration deadline? I understand that for the intended use case it makes sense, but

by d33 5y ago

Just curious... has anyone so far decided to extend the 3-month certificate expiration deadline? I understand that for the intended use case it makes sense, but in some cases it's an overkill and having a CA support such use case could be useful. There's nothing in the technology itself that prevents us from having certs that expire in, say, a year, right?

ttty2 5y ago
I really hope this will happen. Sometimes my infra doesn't play well with let's encrypt. I don't think I'm alone. I just want 1 single docker instance, but because of let's encrypt I need to use docker compose, which is annoying. Each 3 months is a lot of work to do it manually. 12 months acceptable.
gsich 5y ago
I think Buypass has (or had) 6 months.
- Koenvh 5y ago
  Correct, Buypass Go has a validity of six months. Unfortunately the free version does not support wildcards yet.
w3ll_w3ll_w3ll 5y ago
Let's encrypt decided for 3 month to force users to automate and avoid the burden of too much user support. They are a no-profit after all. I believe commercial CA are offering free certificates milted to 3 months for the same reasons, and for the up-selling opportunities. I think also cloud providers offer free 1 year TLS certificates, but of course you are also using their other services.
- hexa22 5y ago
  3 months was an excellent choice because it means you _have_ to automate so it will never expire. While the 1 and 2 year certs always end up expiring on production because someone forgot about them.
  - flemhans 5y ago
    Now you just have to upgrade certbot every 1-2 years instead, it feels like.
    - martin-adams 5y ago
      Did that this morning. Was a complete pain but got there in the end.
    - danuker 5y ago
      I have a Debian server, and it has been running unattended pretty much since I installed it. I warmly recommend it. https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades
      - flemhans 5y ago
        Me too, also on Debian. But there have been different installation methods over the time, certbot via deb package, installation script by piping in a URL, certbot-auto, something in /opt, lost track :D
      - hexa22 5y ago
        I had to look at mine once in 5 years because acme v1 shut down.
  - wbond 5y ago
    It also means you have to automate things that are tied to your certificate lifetime. Apple Pay on the web requires you authenticate your server, and it uses your certificate serial num as proof you still own the server. This means every three months you need to re-authenticate with Apple Pay. But there is no Acme client for authenticating with Apple Pay. So instead, I was having to re-authenticate something manually every 3 months. It involved logging into an Apple Developer account, downloading a PEM file, uploading to my server and then clicking a button in the Developer Account to check the file. After doing that dance, I happily paid for 2 year certificates from RapidSSL. Now you can only buy one year certificates. I really hope the CAB isn’t successful in making those non-conforming and requiring shorter certs. There are plenty of other environments where certificate automation is not possible. And honestly, I haven’t seen arguments as to how on-machine automation is more secure than requiring someone be involved in the process. While I’m dreaming about improvements to the CA ecosystem, having some way to actually prove your are the company you claim would be amazing. Instead we are actively removing support for anything that tried to provide that…
- mytailorisrich 5y ago
  > Let's encrypt decided for 3 month to force users to automate and avoid the burden of too much user support. Yeah, if this is free and you have automated the process then, really, the validity period no longer matters. 1 year, 3 months, 1 month, it's all the same for the majority of purposes.
- cube00 5y ago
  If they insist on keeping the three month limit I wish they'd come up with some better ways to allow you to secure your server. If you want to use the www auth you need to allow outbound connections to any IP (they specifically won't release the range they use), otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised.
  - magicalhippo 5y ago
    With the DNS option the machine doing the request doesn't have to be the machine using the certificate though. I have a separate machine doing the DNS challenge and the cert is then distributed to the machine needing it. Technically true for the regular web challenge, but easier with DNS I think.
    - mimimi31 5y ago
      This is what I do as well. I have set up acme.sh[1] on a Raspberry Pi on my home network, which isn't accessible from the outside. It is triggered every night by a systemd timer and renews (using the DNS challenge) and deploys all expiring certificates. [1] https://github.com/acmesh-official/acme.sh https://github.com/acmesh-official/acme.sh
    - larntz 5y ago
      I'm doing the same for my personal/home lab stuff. I've been using https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns for the dns server running on a small vps for all my internal certificates and I haven't had any issues with it.
  - throw0101a 5y ago
    > If you want to use the www auth you need to allow outbound connections to any IP Only for the time period when you're requesting the cert though: it does not have to be open to the entire Internet 24/7. While this may not satisfy your personal / particular level of security concern, but it is something worth keeping in mind. Using the dehydrated client as an example, the web server could be started and stopped (or the host's firewall rules altered) in the startup_hook() / exit_hook() functions, or the deploy_challenge() / clean_challenge() functions: * https://github.com/dehydrated-io/dehydrated/blob/master/docs/examples/hook.sh https://github.com/dehydrated-io/dehydrated/blob/master/docs... > otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised. Are you aware of LE/ACME's "DNS alias" mode? * https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo... * https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se... Let us say you want to get a cert for foo.example.com. Letting an ACME client change the value of that could be a risk, as you state. So what you can do is (manually) create a CNAME _acme-challenge.foo.example.com, and point that elsewhere, like _acme-challenge.foo.dnsauth.example.com. You then allow the ACME client to alter (just) the TXT records of _acme-challenge.foo.dnsauth. People have even written simple DNS server that allow for updating of records via a RESTful API, so you can server just the (e.g.) dnsauth sub-domain from it, leaving your main domain untouched (besides the initial CNAME addition): * https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns There's also a CLI utility that can handle access the APIs of several dozen DNS companies so you don't have to roll your own if you want to server the sub-domain from your current provider: * https://github.com/AnalogJ/lexicon https://github.com/AnalogJ/lexicon And you don't have to use a sub-domain, but something else entirely too: instead of dnsauth.example.com you can point the CNAME to example-dnsauth.com or example.org. So if your primary DNS provider doesn't have an API, you can use another one that does. The destination CNAME does not matter as long as you control and can update it.
deleted 5y ago
[deleted]
matthewmacleod 5y ago
Certificates used to be issued with validity up to 10 years way back. There's no technical bound on the validity period AFAIK, but all major browsers will now refuse to trust certificates with validity periods > 1 year so this can be considered the practical limit. I'm not aware of a dedicated service that offers free 1-year certs in the style of LetsEncrypt, but they'll often be available from e.g. hosting providers as part of a package. Hard to imagine a use-case where 90-day renewals aren't a better option, anyway.
- norenh 5y ago
  The bound is basically set by the CA/Browser Forum [1] where the current baseline requirements [2] are stipulating: "6.3.2 Certificate operational periods and key pair usage periods Subscriber Certificates issued on or after 1 September 2020 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. Subscriber Certificates issued after 1 March 2018, but prior to 1 September 2020, MUST NOT have a Validity Period greater than 825 days. Subscriber Certificates issued after 1 July 2016 but prior to 1 March 2018 MUST NOT have a Validity Period greater than 39 months. For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional day. For this reason, Subscriber Certificates SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments." - CA-Browser-Forum BR 1.7.9, p67 [1] https://cabforum.org/ https://cabforum.org/ [2] https://cabforum.org/baseline-requirements-documents/ https://cabforum.org/baseline-requirements-documents/
- ttty2 5y ago
  One simple use case... For example I have 1 simple docker app to deploy. Now I need to use docker compose with a more complicated workflow.
maltalex 5y ago
It’s a tradeoff between comfort and security since the fact that you control a domain now doesn’t guarantee you’ll be controlling it in 5 minutes, not to mention 3 months. This is why Let’s Encrypt gives you tools to automate the renewal process. I also recall them talking about gradually lowering the certificate lifetime so you’d have no choice but to use automatic renewal. Relevant link: https://letsencrypt.org/2015/11/09/why-90-days.html https://letsencrypt.org/2015/11/09/why-90-days.html
mtron_ 5y ago
Sectigo provides SSL certificates with 1y validity via their certbot compatible Acme endpoint.
folmar 5y ago
Buypass will get you 6 months.
sigio 5y ago
buypass (also does acme), and uses 180 days expiration on their certs. I've been using it for a while, but they do limit certs to 5 alternate names, instead of the 99 on LE

by d33 5y ago

ttty2 5y ago

I really hope this will happen. Sometimes my infra doesn't play well with let's encrypt. I don't think I'm alone. I just want 1 single docker instance, but because of let's encrypt I need to use docker compose, which is annoying. Each 3 months is a lot of work to do it manually. 12 months acceptable.

gsich 5y ago

I think Buypass has (or had) 6 months.

Koenvh 5y ago
Correct, Buypass Go has a validity of six months. Unfortunately the free version does not support wildcards yet.

w3ll_w3ll_w3ll 5y ago

Let's encrypt decided for 3 month to force users to automate and avoid the burden of too much user support. They are a no-profit after all. I believe commercial CA are offering free certificates milted to 3 months for the same reasons, and for the up-selling opportunities. I think also cloud providers offer free 1 year TLS certificates, but of course you are also using their other services.

hexa22 5y ago
3 months was an excellent choice because it means you _have_ to automate so it will never expire. While the 1 and 2 year certs always end up expiring on production because someone forgot about them.
- flemhans 5y ago
  Now you just have to upgrade certbot every 1-2 years instead, it feels like.
  - martin-adams 5y ago
    Did that this morning. Was a complete pain but got there in the end.
  - danuker 5y ago
    I have a Debian server, and it has been running unattended pretty much since I installed it. I warmly recommend it. https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades
    - flemhans 5y ago
      Me too, also on Debian. But there have been different installation methods over the time, certbot via deb package, installation script by piping in a URL, certbot-auto, something in /opt, lost track :D
    - hexa22 5y ago
      I had to look at mine once in 5 years because acme v1 shut down.
- wbond 5y ago
  It also means you have to automate things that are tied to your certificate lifetime. Apple Pay on the web requires you authenticate your server, and it uses your certificate serial num as proof you still own the server. This means every three months you need to re-authenticate with Apple Pay. But there is no Acme client for authenticating with Apple Pay. So instead, I was having to re-authenticate something manually every 3 months. It involved logging into an Apple Developer account, downloading a PEM file, uploading to my server and then clicking a button in the Developer Account to check the file. After doing that dance, I happily paid for 2 year certificates from RapidSSL. Now you can only buy one year certificates. I really hope the CAB isn’t successful in making those non-conforming and requiring shorter certs. There are plenty of other environments where certificate automation is not possible. And honestly, I haven’t seen arguments as to how on-machine automation is more secure than requiring someone be involved in the process. While I’m dreaming about improvements to the CA ecosystem, having some way to actually prove your are the company you claim would be amazing. Instead we are actively removing support for anything that tried to provide that…
mytailorisrich 5y ago
> Let's encrypt decided for 3 month to force users to automate and avoid the burden of too much user support. Yeah, if this is free and you have automated the process then, really, the validity period no longer matters. 1 year, 3 months, 1 month, it's all the same for the majority of purposes.
cube00 5y ago
If they insist on keeping the three month limit I wish they'd come up with some better ways to allow you to secure your server. If you want to use the www auth you need to allow outbound connections to any IP (they specifically won't release the range they use), otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised.
- magicalhippo 5y ago
  With the DNS option the machine doing the request doesn't have to be the machine using the certificate though. I have a separate machine doing the DNS challenge and the cert is then distributed to the machine needing it. Technically true for the regular web challenge, but easier with DNS I think.
  - mimimi31 5y ago
    This is what I do as well. I have set up acme.sh[1] on a Raspberry Pi on my home network, which isn't accessible from the outside. It is triggered every night by a systemd timer and renews (using the DNS challenge) and deploys all expiring certificates. [1] https://github.com/acmesh-official/acme.sh https://github.com/acmesh-official/acme.sh
  - larntz 5y ago
    I'm doing the same for my personal/home lab stuff. I've been using https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns for the dns server running on a small vps for all my internal certificates and I haven't had any issues with it.
- throw0101a 5y ago
  > If you want to use the www auth you need to allow outbound connections to any IP Only for the time period when you're requesting the cert though: it does not have to be open to the entire Internet 24/7. While this may not satisfy your personal / particular level of security concern, but it is something worth keeping in mind. Using the dehydrated client as an example, the web server could be started and stopped (or the host's firewall rules altered) in the startup_hook() / exit_hook() functions, or the deploy_challenge() / clean_challenge() functions: * https://github.com/dehydrated-io/dehydrated/blob/master/docs/examples/hook.sh https://github.com/dehydrated-io/dehydrated/blob/master/docs... > otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised. Are you aware of LE/ACME's "DNS alias" mode? * https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo... * https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se... Let us say you want to get a cert for foo.example.com. Letting an ACME client change the value of that could be a risk, as you state. So what you can do is (manually) create a CNAME _acme-challenge.foo.example.com, and point that elsewhere, like _acme-challenge.foo.dnsauth.example.com. You then allow the ACME client to alter (just) the TXT records of _acme-challenge.foo.dnsauth. People have even written simple DNS server that allow for updating of records via a RESTful API, so you can server just the (e.g.) dnsauth sub-domain from it, leaving your main domain untouched (besides the initial CNAME addition): * https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns There's also a CLI utility that can handle access the APIs of several dozen DNS companies so you don't have to roll your own if you want to server the sub-domain from your current provider: * https://github.com/AnalogJ/lexicon https://github.com/AnalogJ/lexicon And you don't have to use a sub-domain, but something else entirely too: instead of dnsauth.example.com you can point the CNAME to example-dnsauth.com or example.org. So if your primary DNS provider doesn't have an API, you can use another one that does. The destination CNAME does not matter as long as you control and can update it.

deleted 5y ago

[deleted]

matthewmacleod 5y ago

Certificates used to be issued with validity up to 10 years way back. There's no technical bound on the validity period AFAIK, but all major browsers will now refuse to trust certificates with validity periods > 1 year so this can be considered the practical limit. I'm not aware of a dedicated service that offers free 1-year certs in the style of LetsEncrypt, but they'll often be available from e.g. hosting providers as part of a package. Hard to imagine a use-case where 90-day renewals aren't a better option, anyway.

norenh 5y ago
The bound is basically set by the CA/Browser Forum [1] where the current baseline requirements [2] are stipulating: "6.3.2 Certificate operational periods and key pair usage periods Subscriber Certificates issued on or after 1 September 2020 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. Subscriber Certificates issued after 1 March 2018, but prior to 1 September 2020, MUST NOT have a Validity Period greater than 825 days. Subscriber Certificates issued after 1 July 2016 but prior to 1 March 2018 MUST NOT have a Validity Period greater than 39 months. For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional day. For this reason, Subscriber Certificates SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments." - CA-Browser-Forum BR 1.7.9, p67 [1] https://cabforum.org/ https://cabforum.org/ [2] https://cabforum.org/baseline-requirements-documents/ https://cabforum.org/baseline-requirements-documents/
ttty2 5y ago
One simple use case... For example I have 1 simple docker app to deploy. Now I need to use docker compose with a more complicated workflow.

maltalex 5y ago

It’s a tradeoff between comfort and security since the fact that you control a domain now doesn’t guarantee you’ll be controlling it in 5 minutes, not to mention 3 months. This is why Let’s Encrypt gives you tools to automate the renewal process. I also recall them talking about gradually lowering the certificate lifetime so you’d have no choice but to use automatic renewal. Relevant link: https://letsencrypt.org/2015/11/09/why-90-days.html https://letsencrypt.org/2015/11/09/why-90-days.html

mtron_ 5y ago

Sectigo provides SSL certificates with 1y validity via their certbot compatible Acme endpoint.

folmar 5y ago

Buypass will get you 6 months.

sigio 5y ago

buypass (also does acme), and uses 180 days expiration on their certs. I've been using it for a while, but they do limit certs to 5 alternate names, instead of the 99 on LE