Question

SSL on Ghost blog (+ nginx) suddenly stopped working / "took too long to respond"

Hello,

I noticed today that my small, personal blog wasn’t reachable anymore at its usual url of https://raizenet.hopto.org, with error “… took too long to respond”.

Everything was working the last time I checked, a few weeks ago. Today I wanted to write some posts and found out that the site isn’t reachable anymore except when using the local IP of the machine (a Raspberry Pi 4 running Raspbian Bullseye). Also, whenever connected my browser gives me an error regarding the certificate (which I had generated using Certbot/Letsencrypt).

It’s really frustrating because I haven’t touched anything in any configuration; I may have shut down or rebooted the Pi in these last few weeks, though. Anyway, I tried to understand what’s going on, but I can’t.

My Ghost blog runs in Docker containers. Here’s my docker-compose.yml:

version: '3.3'

services:
  blog:
    image: arm64v8/ghost:latest
    restart: always
    ports:
      - 8080:2368
    volumes:
      - ./data/content:/var/lib/ghost/content
    environment:
      # see https://ghost.org/docs/config/#configuration-options
      TZ: Europe/Rome
      database__client: mysql
      database__connection__host: DB
      database__connection__user: USER
      database__connection__password: PASSWORD
      database__connection__database: DBNAME
      url: https://raizenet.hopto.org
      NODE_ENV: production
      mail__transport: SMTP
      mail__options__service: Gmail
      mail__options__host: smtp.gmail.com
      mail__options__port: 465
      mail__options__secure: "true"
      mail__options__auth__user: "MAIL"
      mail__options__auth__pass: "PASSWORD"

  database:
    image: arm64v8/mysql:oracle
    restart: always
    volumes:
      - ./data/db:/var/lib/mysql
    ports:
      - "13928:3306"
    environment:
      MYSQL_ROOT_PASSWORD: PASSWORD
      MYSQL_DATABASE: DBNAME
      MYSQL_USER: USER
      MYSQL_PASSWORD: PASSWORD
      TZ: Europe/Rome

Here is my /etc/nginx/sites-available/raizenet.hopto.org configuration:

server {

    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/raizenet.hopto.org/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/raizenet.hopto.org/privkey.pem; # managed by Certbot

	ssl_session_cache  builtin:1000  shared:SSL:10m;
	ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
	ssl_prefer_server_ciphers on;

    server_name raizenet.hopto.org;

    client_max_body_size 5M;

    access_log /var/log/nginx/blog.log;
    error_log  /var/log/nginx/blog-error.log error;

    location / {

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://localhost:8080;
        proxy_redirect http://localhost:8080 https://raizenet.hopto.org;
    }


}

Port 443 is open in my router configurations and in ufw too.

I’m unsure if more configurations or files could be useful here so I’ll just wait for some tips on where and what I can look up.

Thank you.


Submit an answer

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!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

Hi @raizelian,

I can see your website is now working, what was the issue?

Usually, in such situations, I’ll start by pinging the Domain, just in case it hasn’t expired. Next, I’ll restart Nginx and any other services that might be experiencing issues. If those don’t help, best to turn attention to the error logs. They always tell you the truth.