266

Currently it is possible to perform DNS validation, also with the certbot LetsEncrypt client in manual mode. Automation is possible as well (see below). Manual plugin You can either perform a manual verification - with the manual plugin. certbot -d bristol3.pki.enigmabridge.com --manual --preferred-challenges dns certonly Certbot will then provide you ...


171

Monthly is not frequent enough. This script should run at least weekly, and preferably daily. Remember that certs don't get renewed unless they are near to expiration, and monthly could cause your existing certs to occasionally be expired already before they get renewed. The name of the program is certbot, which was renamed from letsencrypt. If you are still ...


86

Yes, you can have nginx proxy requests to HTTP servers, and then itself respond to clients over HTTPS. When doing this, you will want to be sure that the nginx<->proxy connect is unlikely to be sniffed by whoever is your expected attacker. Safe-enough approaches might include: proxying to the same host (as you do) proxying to other hosts behind your ...


71

I don't have enough reputation to comment, so I'll answer here. I recently (October 2017) installed and ran certbot on an Ubuntu 16.04 server and a renewal cron job was created automatically in /etc/cron.d/certbot. Here's the cron job that was created: 0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(...


49

The certbot documentation recommends running the script twice a day: Note: if you're setting up a cron or systemd job, we recommend running it twice per day (it won't do anything until your certificates are due for renewal or revoked, but running it regularly would give your site a chance of staying online in case a Let's Encrypt-initiated revocation ...


48

This server could not prove that it is www.zandu.biz; its security certificate is from zandu.biz. This may be caused by a misconfiguration or an attacker intercepting your connection. The name in your site's certificate is zandu.biz, which is not valid for a different name (www.zandu.biz). Moreover, you have a redirect from zandu.biz to www.zandu.biz, ...


40

I was able to use the dehydrated client to obtain a certificate using DNS validation. https://github.com/lukas2511/dehydrated ./dehydrated --cron --domain my.domain.example.com --hook ./hook.route53.rb --challenge dns-01 You'll need to use the correct DNS validation hook for your domain, but there are a few options available as examples: https://github....


38

Indeed, there is no infallible protection against a man-in-the-middle attack for the HTTP-01 challenge. Someone who can intercept traffic between the Let's Encrypt validation nodes and your server CAN pass the challenge and get a cert issued. If they can pull off BGP trickery they may not necessarily even be in the middle in the normal sense. This applies to ...


33

Use: certbot-auto register --update-registration --email new_email@example.com or certbot register --update-registration --email new_email@address.org or certbot update_account --email yourname+1@example.com certbot-auto or certbot will work if you have the executable under /usr/sbin. If you're unable to call certbot-auto globally, use the path to ...


33

My guess is that you have another server listening on port 443. This server has no ssl_certificate defined, and it's automatically selected (SNI). Try to delete all symbolic links from /etc/nginx/sites-enabled except this one server you want to make work (if that's possible, otherwise check all of your servers for listening to 443 without being configured ...


32

You shouldn't have to set up anything. Any recent Debian/Ubuntu install of certbot should install a systemd timer and a cron job (and the cron job will only run certbot if systemd is not active, so you don't get both running). systemd timer You can check your systemd timers using command systemctl list-timers (or systemctl list-timers --all if you also ...


24

The other solutions did not helped me. My solution is to include a negative regex for .well-known. Your code block should look like this then: ## Disable .htaccess and other hidden files location ~ /\.(?!well-known).* { deny all; access_log off; log_not_found off; } It will block every dot file except the ones starting with .well-known P.S.: ...


21

Nginx applies locations with regular expressions in the order of their appearance in the configuration file. Therefore, adding an entry like this just before your current location it will help you. location ~ /\.well-known { allow all; }


21

Try this: server { listen 80; server_name sub.domain.tld; server_tokens off; root /var/www/letsencrypt; location /.well-known { try_files $uri $uri/ =404; } location / { return 301 https://$host$request_uri; } } Since there was no try_files entry in your virtual server, it didn't know what to ...


18

The basic infrastructure, that would make this possible, exists and is called DNS-Based Authentication of Named Entities (DANE) and specified in RFC6698. It works by means of a TLSA resource record, that specifies the certificate or its public key of the end entity or one of its CAs in the chain (There are actually four different types, see the RFC for ...


15

I was having trouble with this as well since Amazon Linux 2 doesn't have epel-release in its repositories, but I've found you can install the EPEL RPM package itself, and then you'll be able to install certbot or certbot-nginx from there. Download the RPM curl -O http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm Then install it sudo ...


12

There is also a contact email address stored by the python letsencrypt client under: /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/{someKindOfHash}/regr.json I believe that if you create multiple certs from the same letsencrypt client instance, it reuses the email address stored in regr.json, at least for expiry alert emails.


12

I fixed this same problem earlier this morning, so I'm here to clarify C.A's point (which, now that I understand the problem, was well made), you most likely have two server blocks: # default server { listen 443 default_server; # Note the lack of `ssl` server_name _; #... } #real site server { listen 443 ssl; server_name ; #... } ...


11

As of today, the official client doesn't support the DNS-01 challenge type (yet). See https://community.letsencrypt.org/t/status-of-official-letsencrypt-clients-dns-01-challenge-support/9427 I haven't looked at this so I don't really know. My high-level understanding was just "no support in our Python client for the DNS challenge yet". You can follow ...


11

The answer to your titled question "Do I need to have port 80 configured in LAMP for an HTTPS website?" is no, you don't. You can run a LAMP stack on whatever port you would like. Common choices include 80,443 (SSL/TLS), 8080, 8000, etc. Inside the question, you add a wrinkle which changes the answer a bit. "Note that I want HTTP to be redirected to HTTPS."...


11

Let's Encrypt requires Internet connectivity, but that is needed by the EFF ISRG who run it. Certbot (which runs on your computer) communicates with Let's Encrypt to issue and renew certs and does require connectivity from your computer. A valid domain name (in the case of Let's Encrypt) is a domain you set up which can be resolved by the global DNS ...


10

I think your problem is DNSSEC-related. There exists a DS record for the zone: [me@risby ~]$ dig ds codestronaut.com [...] ;; ANSWER SECTION: codestronaut.com. 86363 IN DS 19465 8 1 42AFC90FE0A61D3993051C55B6C4C35518713921 but the A record for chat is unsigned: [me@risby ~]$ dig +dnssec +trace chat.codestronaut.com [...] codestronaut....


10

According to: https://community.letsencrypt.org/t/how-to-specify-a-port-different-from-443-for-the-dvsni-challenge/12753/4 This is not possible with certbot. You should take a look at the other implementation method here: https://community.letsencrypt.org/t/list-of-client-implementations/2103


10

I was able to use the lets encrypt certificate on neo4j by using the following process: Used the letsencrypt/acme client implemented as a shell-script method to make the certificate for my domain. Three files are generated running the script to get the certificate fullchain.pem cert.pem privkey.pem Copy them to the certificates directory of neo4j mv /...


10

If you control DNS for the domain then you can use the dns-01 challenge method to prove ownership by creating a TXT-record. This can be done manually or automated. I think even the official certbot client now supports dns-01. A quick Google shows me a bunch of tutorials using various scripts and clients so I won't repeat all of them here. This one ...


10

Please note you have to wait for a while until changes in your DNS zone will be updated on servers worldwide. Your problem is that you're trying to check if changes are applied to the DNS too fast. There is a good way out from this case and it requires using DNS provider's API. If you use for instance OVH, you can use their API for DNS changes and certbot ...


9

Update based on https://letsencrypt.org/docs/expiration-emails/ certbot update_account --email yourname+1@example.com Before This is just an update on n3rve's answer, since certbot-auto didn't work for me: certbot register --update-registration --email new_email@address.org


9

Time passes and it seems that now letsencrypt-auto certonly --standalone now works as expected The README.rst supplied as part of the git repo you reference in your question has this to say nginx/0.8.48+ (highly experimental, not included in letsencrypt-auto) Erm ... that's it. Iain's reading manuals as a service (RMAAS) at your erm ... ...


9

I've provided a full step by step tutorial on how to use Let's Encrypt with NGINX on my website. The key parts are: The official client is only ok, and is really poor on Amazon Linux. I recommend a different client, ACME. Use this location for the webroot method, with my recommend client. Note that the requests are served over http, not https. You don't ...


9

In order to use letsencrypt certificates on the openvpnas you need to have the following symlinks: /usr/local/openvpn_as/etc/web-ssl/ca.crt -> /etc/letsencrypt/live/my.domain/fullchain.pem /usr/local/openvpn_as/etc/web-ssl/server.crt -> /etc/letsencrypt/live/my.domain/cert.pem /usr/local/openvpn_as/etc/web-ssl/server.key -> /etc/letsencrypt/live/my....


Only top voted, non community-wiki answers of a minimum length are eligible