Certbot certonly --standalone fails to get ssl

My Dockerized Application consists of Nginx that serves frontend static files.

My domain is:

I ran this command:
Actually this is the entrypoint script of Nginx container that is being executed when running docker-compose up:
certbot certonly --standalone -m xxxx@xxxx.com --agree-tos -n -d ipharmakey.gr -d www.ipharmakey.gr
nginx -g “daemon off;”

It produced this output:

My web server is (include version):
nginx-alpine latest docker image

The operating system my web server runs on is (include version):
Ubuntu 18.04.3 LTS

My hosting provider, if applicable, is:
AWS EC2 instance

I can login to a root shell on my machine (yes or no, or I don’t know):

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
certbot 0.35.1

Here is my nginx config file (it had been working fine until I tried to get a SSL certificate):
server {
listen 80;
server_name ipharmakey.gr www.ipharmakey.gr;

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
root /usr/share/nginx/html;

location ^~ /.well-known/acme-challenge/ {
    allow all;
    root /usr/share/nginx/html;


location / {
root /usr/share/nginx/html;
index index.html index.htm;
try_files $uri $uri/ /index.html =404;

location ^~ /api/ {
include uwsgi_params;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass :/;
proxy_read_timeout 900;

location ^~ /static/ {
include uwsgi_params;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass _:; #without trailing slash
proxy_read_timeout 900;

Also, both nginx and cerbot error logs are empty.

When I visit the domain, I am greeted by an Apache httpd server.

What I would expect to see is the Cerbot standalone server, or the nginx server even.

Based on the response body included in the Let’s Encrypt error message, it too is receiving a response from the Apache server. So it never sees the challenge response from the Certbot standalone server, resulting in the failure.

Can you comment on how this Apache httpd server relates to your container and domain name? Is it a reverse proxy?

Ah, I think I know what’s happening.

You’ve got your domain pointing at a “web forwarder”, which includes your EC2 server in an HTML iframe.

This isn’t going to work. You need to point your domain name directly at using a DNS A record, and remove the iframe-based forwarder.

Once you do that, all should be well.

I’d also suggest that the way you are going about issuing a certificate is potentially dangerous, if you are not mounting /etc/letsencrypt into a persistent volume. You will very quickly run into rate limits after restarting the container a few times.

1 Like

Just to clarify which of the 4 options you are reffering to.
a) 2 options for forwarding: with masking (ipharmakey.gr url remains) or with redirection
b) 2 options of how to write the destination url 18.219.xxx.xxx or ec2.xxxx.com

Does b option really matters? why?

So, do you suggest the comb a2-b1? or simply a2?

**I concern about the url that is going to be displayed. I would like ipharmakey.gr (that's why I bought it :stuck_out_tongue: )

I’m not really sure how your domain registrar does things. You need to create a DNS A record pointing to your server’s IP.

No redirection, no masking. Neither of those are suitable.

With a DNS record, your browser will show your domain.

Thanks a lot! If I have to make another post, let me know :slight_smile:

So, here are my DNS records at my Domain Registrar

However, I get a connection refused error.

Maybe the second record of www.ipharmakey.gr is a problem? link

Hi @alex5

why do you use --standalone, if you have a running webserver?

Use your running webserver (perhaps with --nginx).

Or use --webroot with your location definition /usr/share/nginx/html.

The main configuration is ok - https://check-your-website.server-daten.de/?q=ipharmakey.gr

The non-authoritative result isn't relevant.

Sorry for not mentioning, I already use this command:
certbot certonly --webroot -w /usr/share/nginx/html -m xx@xx.xx --agree-tos -n -d ipharmakey.gr -d www.ipharmakey.gr

Is there any check for having reached the requests limits? Or this could happen only if I had managed to get at least some certificates?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.