Let’s Encrypt is a Certificate Authority (CA) that provides a way to obtain and install free TLS/SSL certificates, thereby enabling encrypted HTTPS on web servers. It streamlines the process by providing a software client, Certbot, that attempts to automate most (if not all) of the required steps. Currently, the entire process of obtaining and installing a certificate is fully automated on both Apache and Nginx.
In this tutorial, you will use Certbot to obtain a free SSL certificate for Nginx on Ubuntu 18.04 and set up your certificate to renew automatically.
This tutorial will use a separate Nginx server block file instead of the default file. We recommend creating new Nginx server block files for each domain because it helps to avoid common mistakes and maintains the default files as a fallback configuration.
To follow this tutorial, you will need:
One Ubuntu 18.04 server set up by following this initial server setup for Ubuntu 18.04 tutorial, including a sudo non-root user and a firewall.
A fully registered domain name. This tutorial will use your_domain throughout. You can purchase a domain name on Namecheap, get one for free on Freenom, or use the domain registrar of your choice.
Both of the following DNS records set up for your server. You can follow this introduction to DigitalOcean DNS for details on how to add them.
your_domain
pointing to your server’s public IP address.www.your_domain
pointing to your server’s public IP address.Nginx installed by following How To Install Nginx on Ubuntu 18.04. Be sure that you have a server block for your domain. Again, this tutorial will use /etc/nginx/sites-available/your_domain
as an example.
The first step to using Let’s Encrypt to obtain an SSL certificate is to install the Certbot software on your server.
The Certbot project recommends that most users install the software through snap
, a package manager originally developed by Canonical (the company behind Ubuntu) and now available on many Linux distributions:
Your output will display the current version of Certbot and successful installation:
Output
certbot 1.21.0 from Certbot Project (certbot-eff✓) installed
Next, create a symbolic link to the newly installed /snap/bin/certbot
executable from the /usr/bin/
directory. This will ensure that the certbot
command can run correctly on your server. To do this, run the following ln
command. This contains the -s
flag which will create a symbolic or soft link, as opposed to a hard link:
Certbot is now ready to use, but in order for it to configure SSL for Nginx, you need to verify some of Nginx’s configuration.
Certbot needs to be able to find the correct server
block in your Nginx configuration for it to be able to automatically configure SSL. Specifically, it does this by searching for a server_name
directive that matches the domain you request a certificate for.
If you followed the recommended server block set up step in the Nginx installation tutorial, you will have a server block for your domain at /etc/nginx/sites-available/your_domain
with the server_name
directive already set appropriately.
To check, open the server block file for your domain using nano
or your favorite text editor:
Find the existing server_name
line. It should look like the following:
If it does, exit your editor and move on to the next step.
If it doesn’t, update it to match. Then save the file and quit your editor. If you’re using nano
you can do this by pressing CTRL + X
then Y
and ENTER
.
Now verify the syntax of your configuration edits:
If you get an error, reopen the server block file and check for any typos or missing characters. Once your configuration file’s syntax is correct, reload Nginx to load the new configuration:
Certbot can now find the correct server
block and update it.
Next, you’ll update the firewall to allow HTTPS traffic.
If you have the ufw
firewall enabled, as recommended by the prerequisite guides, you’ll need to adjust the settings to allow for HTTPS traffic. Luckily, Nginx registers a few profiles with ufw
upon installation.
You can check the current setting by running the following:
You should receive output like this, indicating that only HTTP traffic is allowed to the web server:
OutputStatus: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Nginx HTTP ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx HTTP (v6) ALLOW Anywhere (v6)
To let in additional HTTPS traffic, allow the Nginx Full profile and delete the redundant Nginx HTTP profile allowance:
Now when you run the ufw status
command it will reflect these new rules:
OutputStatus: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Nginx Full ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx Full (v6) ALLOW Anywhere (v6)
Next, you’ll run Certbot and fetch your certificates.
Certbot provides a variety of ways to obtain SSL certificates through plugins. The Nginx plugin will take care of reconfiguring Nginx and reloading the configuration whenever necessary. To use this plugin, run the following:
This runs certbot
with the --nginx
plugin, using -d
to specify the names you’d like the certificate to be valid for.
If this is your first time running certbot
, you will be prompted to enter an email address and agree to the terms of service. After doing so, certbot
will communicate with the Let’s Encrypt server to request a certificate for your domain. If successful, you will receive the following output:
Output
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/your_domain/fullchain.pem
Key is saved at: /etc/letsencrypt/live/your_domain/privkey.pem
This certificate expires on 2022-01-27.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
Deploying certificate
Successfully deployed certificate for your_domain to /etc/nginx/sites-enabled/your_domain
Successfully deployed certificate for www.your_domain to /etc/nginx/sites-enabled/your_domain
Congratulations! You have successfully enabled HTTPS on https://your_domain and https://www.your_domain
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
* Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
* Donating to EFF: https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Your certificates are downloaded, installed, and loaded. Try reloading your website using https://
and notice your browser’s security indicator. It should indicate that the site is properly secured, usually with a green lock icon. If you test your server using the SSL Labs Server Test, it will get an A grade.
Now that you’ve obtained your SSL certificate, the final step is to test the renewal process.
Let’s Encrypt’s certificates are only valid for ninety days. This is to encourage users to automate their certificate renewal process. The certbot
package you installed takes care of this by adding a renew script to /etc/cron.d
. This script runs twice a day and will automatically renew any certificate that’s within thirty days of expiration.
To test the renewal process, you can do a dry run with certbot
:
If you don’t receive errors, you’re all set. When necessary, Certbot will renew your certificates and reload Nginx to pick up the changes. If the automated renewal process ever fails, Let’s Encrypt will send a message to the email you specified, warning you when your certificate is about to expire.
In this tutorial, you installed the Let’s Encrypt client certbot
, downloaded SSL certificates for your domain, configured Nginx to use these certificates, and set up automatic certificate renewal. If you have further questions about using Certbot, their documentation is a good place to start.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Let’s Encrypt now supports wildcard certificates. It would be great if you add a section to this tutorial about obtaining a wildcard certificate.
Wildcard certificates are not fully supported for some servers at this time.
If you followed this guide, to support wildcard certificates you have to install also the certbot-dns-digitalocean plugin:
Then you will need to create a DigitalOcean API token with both read and write scope and write it into a file as described by certbot-dns-digitalocean documentation (if you think that is too permissive, please upvote the Fine grained API tokens idea). Remeber to keep this file secure with permission since since you can do everithing in your DO account with this token. The suggested location
/root/.secrets/certbot/digitalocean.ini
could be fine, the plugin will tell you if the permissions are not secure. Then, supposing that example.com is the domain that you want to certificate, type:Remeber that
example.com
is not managed by*.example.com
pattern, so you have to declare it if you want a certificate valid also with your domain name only. Having*.example.com
andwww.example.com
is an error, sincewww
is redundant if you have*
, as described by letsencrypt. If you need to remove a certificate, you can type:and selecting the certificate that you want to delete. The renewal acts exactly as described by this guide. If you try to test the renewal immediately after your first certificate generation like this:
and you see an error regarding the
TXT
record of your domain (something likeIncorrect TXT record
), while you have generated the certificate correctly it could be that the DNS record was not propagated to the server required to verify your certificate. Wait a certain time (like the maximum TTL of your records) and then re-do the test.http://schalk.net pointed to my Nginx reverse proxy server that interfaced with my WebSockets server at ws://localhost:3055 inside my droplet. It ran smoothly in Firefox and Chrome, but I wanted more security; so I followed your excellent tutorial.
I was thrilled to see https://schalk.net running smoothly in my Chrome browser, but when I tried to load it in Firefox I got nothing. I pressed F12 and looked at the console. The first screenshot (below) shows an astonishing message that left me momentarily flabbergasted. By encrypting my site, I made it such a tremendous security risk - according to Firefox - that it was too dangerous to load in the browser.
I clicked the message and it took me to line 24 of my sources.js file, a file that Firefox apparently ignored on grounds that everything in the file must be a security risk. Line 24 read, " var socket = new WebSocket(‘ws://localhost:3055/’);". If I change that to “var socket = new WebSocket(‘wws://localhost:3055/’);” Firefox sees no security risk but WebSocket messaging becomes impossible since neither my Haskell backend server nor my Cycle.js front end is set up for WebSocket Secure messaging. I let the Nginx reverse proxy server take care of encryption.
My Bugzilla Mozilla report is at https://bugzilla.mozilla.org/show_bug.cgi?id=1468944. This bug is in versions 62 nightly builds, 61, 60 and I don’t know how far before that. I’m not holding my breath waiting for Firefox to do something, and it won’t help me with web surfers using pre-62 versions.
So, can you suggest any workarounds short of encrypting traffic between my Haskell server and Cycle.js front end? I took a stab at doing that and got frustrated. That’s why I was so overjoyed by your wonderful tutorial - so clear, so thorough, with magic results. Alternatively, can you steer me toward information about using Letsencrypt to secure my WebSocket server and Cycle.js front end?
Any help that you or the community can give me will be much appreciated. Thanks.
tldr
Wow! The procedure you presented was easy to follow and worked like a charm. Very impressive.
I do have a problem, though. Firefox, which loaded my page before I secured the Nginx reverse proxy server, now refuses to load it because of security concerns. Firefox found the file where I define my unencrypted WebSocket server running on localhost and concluded that it is a security threat. This is absurd, of course, but it might be a widespread problem. Every website with a non-secured WebSocket server secured by an encrypted reverse proxy server might be unavailable to people using Firefox browsers. The problem exists in Firefox version 62-daily-builds, 61, and 60. I don’t know about earlier versions.
Do you have any suggestions for a workaround? My application uses a Haskell server behind a Cycle.js front end bundled into the executable file by a Haskell compiler and uploaded to my droplet where it runs on localhost. The thought of transforming it into a WebSocket Secure application is daunting. I shouldn’t have to do that. My secure site loads and functions perfectly in Chrome.
I wrote a comment with specific details, including the URL for my site, but it was deleted by some amateurish spam detection system. Instead of flagging my comment for review, the system deleted it and gave me an email address where I could register an appeal. Treating customers with such disrespect is bad for business. I like Digitalocean and hate to see it messing up like that.
My comment has three screenshots that I dare not attach now lest I upset the automatic comment eraser. Maybe you can retrieve my detailed comment from wherever it went.
Any help from you or the community will be much appreciated. Thanks.
Hi fpschalk. It’s not 100% clear to me what’s going on here, but based on this comment, your previous comment, and your Mozilla bug report, I can suggest a couple of things to look into.
I think there are two basic issues.
https
but then tries to fetch unsecuredhttp
orws
resources. Take a look at Mozilla’s mixed content resources for more info. Chrome might be allowing mixed content forlocalhost
as a special exception, I’m not sure.https://schalk.net
, you should be usingshalk.net
and notlocalhost:3055
in your javascript. I assume you are running a development version of your app locally on port 3055 so this works fine for you in Chrome, but it will fail for your visitors on all browsers.If you fix #2, then #1 will not be an issue as well, because you could use a
wss:
URL since you’ve securedschalk.net
. You may want to try using a websocket test client independent of your code just to verify that the websocket is being proxied correctly.Make sure you get A Record for both versions of your site www.example.com and example.com!
quick links on how to do that: https://www.digitalocean.com/docs/networking/dns/how-to/manage-records/
I’m replying to bboucheron. Pressing “Re;ply” didn’t do anything.
I changed proxy_pass http://localhost.:3055; to proxy_pass http://schalk.net:3055; “socket” is defined as:
MDN’s “Writing WebSocket client applications” states: “In the above examples ws has replaced http, similarly wss replaces https. Establishing a WebSocket relies on the HTTP Upgrade mechanism, so the request for the protocol upgrade is implicit when we address the HTTP server as ws://www.example.com or wss://www.example.com.” – https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications". In context, it is clear that they mean “ws” suffices even for WebSocket Secure sites.
https://schalk.net functions perfectly in Chrome. Firefox has a new concern. In the Webpack bundle;js file, String.prototype.split is defined as native JavaScript String.prototype.split unless Regex is used in calling it. In that case, it appears that MIT licensed “Cross Browser Split 1.1.1” by Steven Levithan is used. Well, you guessed it, my application doesn’t finish loading in Firefox and the console explains “SecurityError: The operation is insecure”, as shown in the screenshot I will attempt to upload. Clicking the error line causes page 1818 of Bundle.js to be displayed. This is shown in another screenshot and also, in more detail, in the text file that I will try to upload.
I write “try to upload” because when I first left my two redundant messages they were immediately deleted by the spam robot. Digital Ocean was very good about republishing them, but I doubt that they have had sufficient time to substantially improve their spam software.
I am very grateful to you for helping me. I guess I should tell Webpack that Firefox thinks that altering String.prototype can be an “insecure” operation. I’m feeling a little insecure about developing websites that have to work in Firefox browsers. Do you or anyone else reading this think a hacker could make use of Webpack’s modified version of String.protocol.split?
I edited the bundle.js file produced by Webpack so String.prototype.split is no longer modified. Now loading of my app in Firefox stops when the definition of “socket” is reached. It is ordinary “ws”, not WebSocket Secure. My bundled Haskell server and Cycle.js front-end exchange unencrypted WebSocket messages inside my droplet. Users reach the app with the URL https://schalk.net, the address of my secure reverse-proxy Nginx server.
Chrome runs smoothly, but Firefox won’t finish loading. Here is the definition of “socket”: socket = “MozWebSocket” in window ? new MozWebSocket(‘ws://127.0.0.1:3055/’) : new WebSocket(‘ws://127.0.0.1:3055/’);
I’m not the only one having this problem, as is evident from:
https://www.google.com/search?ei=lysvW6efB6WLjwT4uYfICQ&q=mixed+content+blocking+https+“ws”&oq=mixed+content+blocking+https+“ws”&gs_l=psy-ab.12...21871.23660.0.24677.2.2.0.0.0.0.103.182.1j1.2.0....0...1.1.64.psy-ab..0.0.0....0.DopyQx_CZug
CAUTION
If have - like me - your domains (and associated dns, nameservers) sit behind a service like cloudflare, the above setup might need one more little tweak to avoid the headache of a redirect loop.
Basically I have the non-httpS endpoint redirect to httpS, and it got stuck in a redirect loop. But when I commented out the certbot and ssl stuff from my nginx server block, all was good. The root cause - at least for me - was that cloudflare provides its own ssl cert…so as Joe Fleming stated on his recent blog post: within cloudflare you need to “…switch the crypto config to Full SSL or Full SSL (Strict)…” (by default it usually is configured as “Flexible” (or something similar).
Reference: https://joefleming.net/posts/nginx-ssl-and-cloudflare/
Once I did that tweak in cloudflare all was good, and I was able to stop pulling my hair out, and live a happier day.
Big props to Joe Fleming for posting this solution on his blog (I’m surprised google didn’t bring up any other hits on this topic except for Joe’s)…and as always props to the digital ocean folks for posting these instructions!
You just saved me so much headache! I’ve been struggling with this for a few hours. Thanks!
Good news. My site ( https://schalk.net) works flawlessly in Chrome AND FIREFOX. Firefox was complaining about Webpack’s definition of String.prototype.split and secure Nginx reverse proxy server in front of unsecured WebSocket communication between my Haskell WebSockets server and Cycle.js. I thought this is what I originally had in /etc/nginx/sites-enabled/schalk.net but I don’t know what else I changed. I had a Warp server behind Index.html with scripts including the Webpack bundle.js file but that is currently stopped. Anyway, thank you for a great tutorial and here’s /etc/nginx/sites-enabled/schalk.net:
Automatically inserted by Certbot:
I was able to enable the SSL by changing the server_name to a domain name instead of IP. But i can no longer access thru ssh. How can i access now thru ssh?
I know very little about system administration. l uploaded my WebSockets/Cycle.js executable, put a little Upstart script in /etc/init, and my site went live on the Internet. It was like magic. I went back to writing project code and didn’t give Upstart a second thought.
Trying to run my executable, which is a Haskell-compiled WebSocket server / Cycle.js app combination, was a different story. The magic was gone. While trying to make it go live on the Internet, I wrote some nonsensical comments below. I meant well, but now I think reading my comments would be a waste of time. I will delete them when I figure out how.
Edit suggestion: Add step after adding the repository to
sudo apt update
. I had to run that for Ubuntu to see thepython-certbot-nginx
packageAre you sure you are on 18.04?
I definitely was yea.
Under Step 1 - Installing Cerbot after adding the repository.
sudo add-apt-repository ppa:certbot/certbot
You’ll probably need to runsudo apt update
.Great tutorial! I am happy I found Digitalocean services and their amazing documentation. Keep up the good work guys!
thanks. this tutorial saved my day
thanks, good tutorial to get started
I have been following the guides for installing WordPress on Ubuntu as part of a larger personal project of mine to migrate a site from one droplet to another. The former I had setup awhile back and I had lazily not setup SSL encryption for HTTPS connections, but I was on this one.
As part of the following the guide I setup port 80 requests to forward to https:// and before adjusting my DNS settings to point to the new site I tested encryption without a CA using just the new IP address.
After everything appeared to be working I changed my DNS entries from the old IP address to the new one and… suddenly pulling up my site only gave me the nginx landing page. I also had already made sure to update my .conf file from the new IP address to the domain name instead.
It occurred to me that it might be the redirection that was causing the problem (I was trying to confirm success at each step rather than implement all changes at once) so went ahead with this guide and it did solve the problem.
Mostly posting this in case anyone else finds themselves in a similar situation at some point and stumbles across this while searching for a solution.
(I can follow guides and do basic troubleshooting but most of this stuff is outside my wheelhouse.)
Hi, I followed your tutorial and after restart NGINX and network configuration, I am just seeing the NGINX site. It should request the http://localhost:4000 (server side rendering index.html) but it didn’t work. I have also add the A records like www -> @ and test.com -> host ip
What I am doing wrong?
There’s a problem with the last step in step 1 (installing Python). The solution that worked for me is here:
https://github.com/certbot/certbot/issues/6362
sudo add-apt-repository universe sudo apt-get update
then install certbot
For step 5 (checking if auto-renewal is set up correctly) I had to restart nginx for a successful dry-run.
Thank you! I wasted some time figuring this out. Anyone running GitLab (and hence another nginx) may get this issue, as port 80 will be used by GitLab’s Nginx. (at least for me that was the case).
Hello everything went great until I hit a problem in step four. When it goes to obtain a new certificate, it says it can not find the www.example.com version of my domain name. The challenge for the example.com seems to be fine.
Error Detail says: DNS problem: SERVFAIL looking up A for www.example.com
I double checked to make sure I have a A record for www.example.com. I just added the record a few mins before getting to this step. Is it possible it just hasn’t taken effect yet or did I maybe set up that record wrong? Thanks for any help!
Probably needs several minutes to take effect (it did for me)
I found that you have to update apt after adding the certbot repo with: sudo apt update before installing certbot else it gives ‘unable to locate python-certbot-nginx’
Thx!! Easy peezy with this tutorial!
Does this not work anymore?
I’m getting emails from LetsEncrypt
TLS-SNI-01 validation is reaching end-of-life. It will stop working temporarily on February 13th, 2019, and permanently on March 13th, 2019. Any certificates issued before then will continue to work for 90 days after their issuance date.
You need to update your ACME client to use an alternative validation method (HTTP-01, DNS-01 or TLS-ALPN-01) before this date or your certificate renewals will break and existing certificates will start to expire.
…
…
works
The problem is the “The certbot package we installed takes care of this for us by adding a renew script to /etc/cron.d” uses the first command and not the second one.
Thanks for the tutorial to install SSL certificate. When I follow the instructions for my site together with How To Set Up Django with Postgres, Nginx, and Gunicorn on Ubuntu 18.04 https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-18-04, my site does not load on browser. Server terminal curl shows the website index.html, yet it does not load on anywhere else.
On my computers terminal, curl responds with curl: (7) Failed to connect to mysite.com port 443: Connection refused.
Could you help me on how to solve this?
I have been trying to solve this issue for some time, but no luck yet. My website works well without https certificate. Yet, when I follow this instruction, neither http or https connection works. Could anyone help me on this?
My sites-available/mysite.com file:
great, thanks
that was easier than I thought. I always thought that enabling HTTPS would be harder but letsencrypt makes it really easy. Thank you to Digital Ocean team for the great tutorials!
Two questions/ clarifications, please. Q1: This setup allows for both ‘example.com’ and ‘www.example.com’ Is the subdomain ‘www.example.com’ needed or required for certbot to work correctly? Can ‘www.example.com’ be 301 rewritten to just ‘example.com’ before or after certbot/ letsencrypt install?
Q2: certbot/ letsencrypt installation and renewal suggests several times to download and safely store copies of the certs. Any pointers or guides on how to do so? Quote: “… This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal.”
Thanks in advance
I’d really appreciate a help now. Followed this instructions - and now site cannot fetch anything from server, getting: `GET https://{domain}:30001/{uri} net::ERR_CONNECTION_CLOSED error. Nginx error log shows nothing. Access log has no such request string in it :\
Thank you for this very clear manual!
Unfortunately a piece of javascript code doesn’t work anymore after securing the website with Certbot.
It is javascript for automatically scrolling a textarea to the bottom:
This code does work after: sudo ufw allow 8000 python manage.py runserver 0.0.0.0:8000
but not through the nginx web server.
Is there any way to get this javascript code working again in the production environment?
Many thanks in advance.
Hi there @JackJansonius,
The reason this isn’t working currently is because the request to load the jQuery library is being made with an insecure
http
request.As your site is now using
https
, the browser won’t allow insecure requests to be made from your page. To fix this, you just need to make the request for jQuery usehttps
.Hope that helps! - Matt.
Hello @MattIPv4 Thank you for your clear answer!
One simple ‘s’ and it works again! :-)
Great!
Kind regards, Jack
As of January 2020, TLS 1.0 and 1.1 are deprecated, and you will no longer receive an A grade from the SSL Labs Server Test with Nginx out of the box, like you would originally in this guide.
To receive an A, you must edit your Nginx configuration to allow only TLS 1.2 and 1.3. The three files you must change are
/etc/nginx/nginx.conf
,/etc/nginx/sites-available/example.com
, and/etc/letsencrypt/options-ssl-nginx.conf
.There will be a line with
ssl_protocols
. It will probably say:Edit this line in all 3 files to the following:
Restart with
sudo systemctl restart nginx
and run the SSL Labs Server Test again, and you should get an A.Yes, I had to apply the above recommendation once I completed all the steps successfully. Thanks for sharing the above steps and I see A grade from testing. I’ve to let you know this ‘/etc/nginx/sites-available/yourdomain.com’ file did not have TLS entry at all. Hope this is fine?
Hi,
I’m able to configure every step successfully and then updated the configuration with TLS 1.2 and 1.3. I also got an A grade from the test URL. https://www.ssllabs.com/ssltest/analyze.html?d=www.vikreya.com
but my site is still showing not secure when I launch it https://www.vikreya.com
Please let me know what I’m missing?
Having problems on Ubuntu 20.04:
AttributeError: module ‘acme.challenges’ has no attribute ‘TLSSNI01’
Dirty Workaround from here:
For a very fragile workaround, you can edit /usr/lib/python3/dist-packages/certbot_nginx/configurator.py and replace return [challenges.HTTP01, challenges.TLSSNI01] with return [challenges.HTTP01] (or you… can use the webroot plugin)
There’s a newer version of this article now for Ubuntu 20.04: https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-20-04
Hi, this article was amazing… congrats! I’m trying to configure the SSL certificate for my Spring Boot application. I’ve generated my Keystore but I don’t know to import my domain certificate file into it. Can you share some ideas on how to do that?
Thanks in advance.
Very helpful tutorial!
One thing that is stopping it from ‘perfection’ is that I have encountered an error when performing this in an EC2.
In the event that you add an ADDITIONAL APP to the EC2, and run these steps for certification, it breaks the original app’s permissions.
I have had difficulties restoring the original functionality.
If this post is still monitored, is there a list of files that are effected during this process? Any low-hanging fruit fixes?
Thank you
I get a B :/
Some other comments address this shortcoming of the tutorial: https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-18-04?comment=85617
Specifically Nirc’s on February 26, 2020.
also, if you’re using Ubuntu 20.04, use this more recent tutorial instead and you should get an A https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-20-04
Cron is just the worst. I was already using systemd and systemd takes precedent over cron by default. So the installed renewal timer found in /etc/cron.d/certbot is not going to run because systemd is active.
This is the note from /etc/cron.d/certbot:
So here’s a great article detailing how to use systemd to invoke autorenewals. It’s a much better system I believe and so much easier to understand for anyone not intimately familiar with cron: https://stevenwestmoreland.com/2017/11/renewing-certbot-certificates-using-a-systemd-timer.html
By default on Ubuntu 18, the package in this tutorial will not install any systemd timers, so follow that tutorial to learn how easy it is.
It would be great if this was rolled into the main article, or future articles.
A nice tutorial and very useful. thank you.
When I follow these instructions after the other basic tutorials:
https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04 and https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-18-04
… I get the same issue every time. sudo certbot renew --dry-run always fails and gives the following message (with my actual domain of course):
Attempting to renew cert (EXAMPLE.com) from /etc/letsencrypt/renewal/nextleveloa.com.conf produced an unexpected error: (‘Connection aborted.’, ConnectionResetError(104, ‘Connection reset by peer’)). Skipping. All renewal attempts failed. The following certs could not be renewed: /etc/letsencrypt/live/EXAMPLE.com/fullchain.pem (failure)
Does anyone have any idea what might be causing this? I’ve tried a few times following all instructions precisely, so I don’t think it’s an issue with my specific setup.
When I try to install Certbot for Nginx and run: “sudo apt-get install python-certbot-nginx”, I kept getting “E: Package ‘python-certbot-nginx’ has no installation candidate”. It looks like Python2 is no longer supported. You need to ask for Python3: “sudo apt-get install python3-certbot-nginx”. This is what worked for me.
Hi, Is a domain name mandatory? I don’t want to setup a production business site or anything like that. Just a personal site. I wish there was a solution similar to dyndns or something. ( I know they no longer have free domains ) I did read some of the comments, and see the wildcards certificate but it does not seem to address my concern since I still need to get a domain. My concern with the suggested domain vendors is that 1- I really do not want to pay for a domain 2- The free ones come with a comment that there might be taxes associated with it and etc. I rather be clear about the cost. I wish there was a certificate that says this site is one of DO hosted sites or something. The more important point in all this is that the end user still has to accept my certificate. Is that not the case?
sudo add-apt-repository ppa:certbot/certbot cause error “updating from such a repository can’t be done securely, and is therefore disabled by default.”
Is it a way to allow Https without ufw ? I’m on a shared server with other people who ask me to not install firewall
I finished the instructions and got it to work if I type in:
example.com or https://www.example.com
but NOT www.example.com. Any idea how to fix this?
I got this error:
But I already have an A record - for mydomain.ai (not www.domain.ai though)
Where am I going wrong?
My tutorial example doesn’t display, I just see the default nginx server welcome page
IMPORTANT Make sure you disable or unlink the default sites or Let’s Encrypt will not work
This comment has been deleted
If you don’t find a cronjob script under /etc/cron.d, try
systemctl list-timers
Dream come true learning this.