What are /r/letsencrypt's favorite Products & Services?

From 3.5 billion Reddit comments

The limit for a domain is 50 per week. There's no way to reset the request limit. You have to wait a week from the time you requested the first certificate.

You say it's a joke, but I think you raise a serious point. I too had noticed the length of their certificate and where it came from. It does seem to fly in the face of a recent Let's Encrypt blog post.

Up-to-date clients should accept the certificate issued by this command: certbot renew --force-renewal --preferred-chain "ISRG Root X1"

> Is there anything that visitors on their older Windows computers can do?

They can update their system which hopefully updates outdated root certificates, or install the ISRG Root X1 certificate manually.

According to their doc > Informations utiles > §5:

> Il n'est actuellement pas possible sur un hébergement Web d'ajouter un certificat SSL externe.

> It is not currently possible to add an external SSL certificate to web hosting.

How does it work though?

I'm using this command: ./certbot-auto certonly --manual --preferred-challenges dns-01 --email -d xxxx.duckdns.org

I get this output

Please deploy a DNS TXT record under the name

_acme-challenge.xxxx.duckdns.org with the following value:

g0FKLWUmwqJs4htXsZzbfGhorf9y4xQOlLTerZMbVJw

Once this is deployed

Press Enter to Continue

Going by this link at DuckDNS, I know I'm supposed to do something like populate that URL with this key and modified domain name, but I'm not sure at all

https://www.duckdns.org/spec.jsp

I just saw this- https://letsencrypt.org/2016/09/20/what-it-costs-to-run-lets-encrypt.html

So that is roughly $USD 0.5 per certificate/year? I think they hit 5M active certificates recently, and I padded a little for growth and then rounded.

I would gladly and voluntarily pay that (and a little more) for the certificates that I have.

Done! - You've donated $XXX to Internet Security Research Group

For a simple setup, to use letsencrypt on a private network, your local webserver has to be able to receive traffic from the outside. You can avoid this, but it makes things more complicated.

I use letsencrypt for my private network and I found the DNS challenge to be very useful for this.

The default http challenge proves you control the domain by serving a file at a special path that letsencrypt can access. The DNS challenge proves you own the domain by updating a public DNS record.

Note that with this setup, you have to have publicly accessible dns for your private domain. It doesn’t have to contain all the same records as your private domain, but it has to exist.

Here’s some info on the dns challenge: https://letsencrypt.org/docs/challenge-types/

This works best if you have DNS you can programmatically update, like Route53, google cloud DNS, etc. Here’s a tutorial for Route53: https://johnrix.medium.com/automating-dns-challenge-based-letsencrypt-certificates-with-aws-route-53-8ba799dd207b

Hope this helps a little.

That worked! The guide I was following left that part out. I appreciate the help. Thank you very much.

I had all sorts of SSL issues with Freenas 11, just deploying plugins, since freebsd.org uses LE. This was related to the root CA expiring September 30, 2021. See https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

Upgrading to Freenas/Truenas 12 sorted the issue for me.

Are you using Let's Encrypt? Let's Encrypt will start with HTTP, but will also follow redirects. If the certificate is expired, Let's Encrypt will ignore the certificate. See documentation.

The TXT record is only required for DNS-01 domain verification. If Certbot works without you having provided an API key for your DNS provider, you must be using HTTP-01 domain verification.

You can also create a CAA DNS record which improves security a little more, but it's not required for Certbot to work.

Not really. Upstream is meant in the context of the siging party of your cert (eg, the authority, which is letsEncrypt)
https://letsencrypt.org/certificates/
Your browser sees your SSL cert (on https) and agrees with it because it recognizes the signing party (letsencrypt) of that cert. the app probably does not recognize the signing party (letsencrypt), but can be helped to recognize it by providing an intermediate key (or more than one in the) chain up to a point where it recognizes a signing party (IdenTrust, ISRG) as being a valid and trusted signing party. Which parties are trusted depends on the app, which probably asks the OS, which has a store of valid certs for those parties form around the world. However, those lists can get out of date, and should be kept up to date as those signing parties might have their authority (or specific keys) be revoked.

Whatever happens behind your nginx proxy is not relevant to this question or ssl, as long as your client connects over https to the nginx proxy.

DNS-01 and HTTP-01 are the only official challenge types for letsencrypt - https://letsencrypt.org/docs/challenge-types/

If your DNS provider doesn't have an API, you're left with doing HTTP-01. If you cant allow any of your internal servers to accessed externally, you might want to consider setting up a server in a restricted DMZ, use it to validate a letsencrypt wildcard certificate, and then pull the public/private keypair back into your network for distribution to your servers. Then you'll need to setup some sort of automation that will spin up your VM & DMZ and refresh your certificates on a schedule. Terraform perhaps?

Possible, but definitely a lot of work.

imo certbot is a mess, it does everything but nothing well.

Just configure your webserver as any sane person and use any simple le-client to issue your certificate, see https://letsencrypt.org/docs/client-options/

i'm a fan of dehydrated, but your mileage may vary.

Alternatively any web server / proxy that supports le natively is just fine.

This is Let’s Encrypt’s multi-perspective validation in action. You could whitelist these specific IPs, but there’s no guarantee they won’t change. I wouldn’t be surprised if LE added more validation servers - the attack multi-perspective validation mitigates gets progressively more difficult with each new validator, especially if the validators have diverse paths to the internet.

Can you use DNS validation? You don’t need to open your firewall at all to complete a DNS challenge.

I think error output goes only to stderr by default. Perhaps try running certbot with the --dry-run flag, which uses their staging environment. If there are errors reaching your webserver for validation, they should appear when you use the staging environment as well. (The staging environment has higher limits, but won't actually give you a cert that browsers will trust. It's useful in situations like this. https://letsencrypt.org/docs/staging-environment/)

Hope that helps!

You could replace the intermediate certificate that your Let's Encrypt client gives you with the version signed by ISRG Root X1, which is SHA256:

https://letsencrypt.org/certificates/

However, this isn't recommended because a) the default IdenTrust (DST) cross-signed version has better compatibility with older browsers, and b) if you forget about this manual override, a future change in the trust chain might break your site.

We now have a date from the new blog post that just went up: https://letsencrypt.org/2017/12/07/looking-forward-to-2018.html

> Wildcard certificates will be free and available globally just like our other certificates. We are planning to have a public test API endpoint up by January 4, and we’ve set a date for the full launch: Tuesday, February 27.

If I'm interpreting your question correctly, then no, it's not quite possible. In order to decide which certificate to present to the client, Postfix would need to support the SNI extension to TLS. Postfix only supports this when it's acting as a client: "There are no plans to implement SNI in the Postfix SMTP server."

If you pointed each domain to its own IP address, and defined a separate smtp instance in master.cf for each one, that would work - but it would be an inefficient use of IPs.

You'll pay for queries against your domain anyway, right? (https://cloud.google.com/dns/pricing)

It sounds like you should just enable the Cloud DNS API. If you're concerned about paying a lot of money, I have a few Route 53 domains (AWS Route 53 is what Google Cloud DNS is competing with) and the domain monthly cost and all my queries run me about $3/mo.

Yep! Their (our) free tier covers most small to medium sites just fine. I used it for mine for years.

It is worth noting that with the free tier, this will be a shared certificate. What that means is that if someone digs into your certificate details, they'll see that it's a cert for several sites including yours. However most won't notice as this'll present that lovely HTTPS padlock in browsers and you have to dig in to notice that. And it's not that big of a deal to most people unless you're running a site that needs an extremely high level of security like a payment processor.

Is this complicated? Up to you, I suppose.

sudo docker run -it --rm --name certbot \
            -v "/etc/letsencrypt:/etc/letsencrypt" \
            -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
            certbot/certbot certonly

As mentioned, it would be better to use the DNS-01 challenge rather HTTP-01, assuming your DNS host has an API supported by Cerbot.

Let's Encrypt has specifically declined to list any IP addresses that the challenge will be made from so that people don't whitelist or otherwise treat the challenge specially.

If your team is adamant that port 80 needs to remain closed to general traffic, you could write custom webserver or firewall configuration to route traffic from all non-whitelisted IPs to a different internal port and run a second webserver on that port just for the ACME challenge, but that would be getting a little silly.

Generate-locally-and-deploy isn't really the Let's Encrypt workflow. Since the certificates only last 90 days, you're expected to create an automated set-up with Certbot.

I've done something similar to you; a nginx reverse proxy to a backend in Docker. I terminate HTTPS in nginx, and just run plain HTTP to the backend. To pass the challenge, I have the nginx server configured to handle all requests to the /.well-known/acme-challenge/ route. My configuration looks something like this:

# Catch routes to be served by this webserver location ^~ /.well-known/acme-challenge { }

# Forward most requests to the local application server location / { ... proxy_pass http://127.0.0.1:3000; }

Also bear in mind that there's no single "ACME challenge", but rather separate HTTP-01 and DNS-01 challenges. If you use a DNS provider which Certbot supports, it might be easier to use a DNS-01 challenge.

Nothing which can't be fixed! Firstly, are you trying to host two separate websites with separate root directories, or host one website served at two different domains?

If the former, I'd recommend two different certificates. Certbot may not be able to do this automatically, so I'd recommend using <code>certbot certonly</code> and specifying the domains and their respective directories. It might look something like this:

certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com certbot certonly --webroot -w /var/www/anotherone.com -d anotherone.com -d www.anotherone.com

This will create two certificates which nginx will need to load. You'll need different ssl_certificate and ssl_certificate_key directives in your config.

If you instead want one website with two different domains, you should probably just create one certificate which covers all of the hostnames. Using certonly again, this might look like this:

certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com -d anotherone.com -d www.anotherone.com

If you want one of the domains to redirect to the other, that'll need to be done in the nginx config.

With either of these options, you can run certbot renew when the certificates are nearing expiry to get new ones. Certbot should have a cron job configured since installation that will run this roughly twice a day.

I believe it; Firefox defaults to its own CA store rather than the OS one, and I've never had any luck getting Android to trust a root CA. No possibility of switching DNS host? Is there a big provider that's missing from their list? Azure DNS?

Yeah, I think it only really works for the simplest webserver configs. I appreciate them trying to make TLS as easy as possible, but automatic re-configuration sounds like it would be very difficult to get right.

Just had another look at the certbot docs, and there's actually hook functionality. When you run certbot certonly, I think you can add --post-hook 'systemctl reload nginx' or --post-hook /etc/nginx/reload-nginx.sh (and then put the command in that file instead). There's also --pre-hook and --deploy-hook if you want to do something before renewal or once per certificate. I think certbot will remember these and run them whenever you run certbot renew, which certbot adds to the crontab during install.

Look here or look at man certbot.

Yeah, this is a bit of a revelation for me as well. I had been looking into alternatives because of our hosting setup (acme.sh being the top candidate). I also saw they offer a snap installation (in beta), so that might be a good option.

Hi,

&#x200B;

First of all, I want to clarify that I'm not affiliated to Let's Encrypt or certbot.

Every time I or someone else update the post, it will effectively overwrite the original/old post. So what you see now it's the latest version.

certbot also holds their own version of the list, which is derived from the original list. I also planned to merge the list on Let's Encrypt to the new list completely.

https://certbot.eff.org/hosting_providers/

&#x200B;

Thank you

Thank you, that clears things quite a bit. So, that means this process should be followed on my Box1 (nginx reverse proxy) to generate the certificates.

I found a different method which involves going through github instead.

Any idea whether it matters what route I take? guthub sounds like an up to date method.

This and this will help. Without knowing what kind of device you have we can't really give more specific instructions. Tell the second link what software you have, it will give you instructions.

> Because others may rely on your use of Your Certificates to encrypt Internet communications, much of the > information You send to ISRG will be published by ISRG and > will become a matter of public record.

Updated Service Agreement, page 4

I'm not sure what this means; the launch ("General Availability") was previously planned for November 26... Instead we get a beta on December 3? That sounds like a huge setback, written up as a progress report.