Letsencrypt is generating self signed certificate, not wanted

Question

I'm struggling with generating certificates for my nginx proxy on Docker.

I've designed the docker-compose in the following way:

version: "3"
services:
  postgres-db:
    image: postgres:15.2-alpine
    container_name: postgres-db
    restart: unless-stopped
    env_file:
      - .env
    volumes:
      - ./postgres-data:/var/lib/postgresql/data
    ports:
    - "5432:5432"
    networks:
      - container-network

  app1:
    image: app1:development
    container_name: app2
    restart: unless-stopped
    env_file:
      - .env
    ports:
      - "3002:3000"
    networks:
      - container-network

  app2:
    image: app2:development
    container_name: app2
    restart: unless-stopped
    env_file:
      - .env
    ports:
      - "3001:3000"
    networks:
      - container-network

  nginx:
    image: nginx:latest
    container_name: nginx
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./certbot/www/:/var/www/certbot/:ro
      - ./certbot/conf/:/etc/letsencrypt/:ro
    networks:
      - container-network

  certbot:
    image: certbot/certbot:latest
    container_name: certbot
    volumes:
      - ./certbot/www/:/var/www/certbot/:rw
      - ./certbot/conf/:/etc/letsencrypt/:rw

networks:
  container-network:
    driver: bridge

And my nginx conf is the following:

worker_processes 1;

events {
    worker_connections 1024;
}

http {
    server {
        listen 80;
        server_name app1.com www.app1.com;
        server_tokens off;

        location /.well-known/acme-challenge/ {
            root /var/www/certbot;
        }

        location / {
            return 301 https://$host$request_uri;
        }
    }

    # Redirect all http traffic to https
    server {
        listen 443 ssl;
        server_name app1.com www.app1.com;
        server_tokens off;

        ssl_certificate /etc/letsencrypt/live/app1.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/app1.com/privkey.pem;

        include /etc/letsencrypt/options-ssl-nginx.conf;
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

        location / {
            proxy_pass http://app:3000;
            proxy_set_header    Host                $http_host;
            proxy_set_header    X-Real-IP           $remote_addr;
            proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
        }
    }
    server {
        listen 80;
        server_name app2.app1.com
        server_tokens off;

        location /.well-known/acme-challenge/ {
            root /var/www/certbot;
        }

        location / {
            return 301 https://$host$request_uri;
        }
    }

    # Redirect all http traffic to https
    server {
        listen 443 ssl;
        server_name app2.app1.com
        server_tokens off;

        ssl_certificate /etc/letsencrypt/live/app2.app1.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/app2.app1.com/privkey.pem;

        include /etc/letsencrypt/options-ssl-nginx.conf;
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

        location / {
            proxy_pass http://app:3000;
            proxy_set_header    Host                $http_host;
            proxy_set_header    X-Real-IP           $remote_addr;
            proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
        }
    }
}

I've managed to generate the necessary certificates using the script provided here, yet when accessing my website, my browser is warning me about ERR_CERT_AUTHORITY_INVALID errors, and telling me that the issued certificate has a "localhost" common name.

All the files are running and nginx doesn't seem to complain too much...

To be clear, this is not what's expected, I'm expecting a certificate for my app.com domain.

Am I missing a certificate or a step in the process?

Answer 1

Your issue with Let's Encrypt generating a self-signed certificate instead of a valid certificate for your domain is likely related to the configuration of your Docker setup and Nginx, or the process you followed to obtain the certificate. Here are some steps to troubleshoot and resolve this issue:

1. Verify Domain Configuration: Ensure your domain app1.com and app2.app1.com are correctly pointing to the public IP of the server where Docker is running. This is crucial for Let's Encrypt to validate your domain.
2. Check Certbot Configuration: Make sure you've correctly run Certbot to generate certificates for your domains. This usually involves running a command similar to certbot certonly --webroot -w /var/www/certbot -d app1.com -d www.app1.com and similarly for app2.app1.com. These commands should be executed on the server, and you should see output indicating successful issuance.
3. Nginx Configuration: Your Nginx configuration seems correct in terms of pointing to the Let's Encrypt certificates. However, ensure that the paths /etc/letsencrypt/live/app1.com/fullchain.pem and /etc/letsencrypt/live/app1.com/privkey.pem are accessible by Nginx inside the Docker container.
4. Docker Volumes: Double-check the Docker volume mappings in your docker-compose.yml. Make sure the paths for Let's Encrypt certificates are correctly mounted into the Nginx and Certbot containers.
5. Logs Inspection: Look into the logs of both Nginx and Certbot containers. Sometimes, the logs can provide hints about misconfigurations or errors during the certificate issuance process.
6. Firewall and Ports: Ensure that your firewall and network configuration allow external access to ports 80 and 443, as these are required for the ACME challenge during the Let's Encrypt certificate issuance.
7. Renewal Script: If you used a custom script for certificate renewal, ensure it's correctly configured and executed. Certbot typically handles renewals, but any custom scripts should correctly point to the right domains and webroot paths.
8. Certificate Permissions: Sometimes, permission issues on the certificate files can cause problems. Ensure that the certificates in /etc/letsencrypt/live/ have the appropriate read permissions.
9. Debugging: If the issue persists, you may run Certbot in a more verbose mode to get detailed logs that can help identify the issue.

If you've confirmed all the above and still face issues, it might be helpful to manually run the Certbot command outside of Docker to see if there's an issue with the Docker environment or the Certbot configuration itself.