Вопрос или проблема
Мой предыдущий SSL сертификат только что истек.
Я попытался купить другой бесплатный SSL сертификат у AliCloud и также на sslforfree.com. Я почти уверен, что уже установил правильный сертификат на сервере. Но когда я проверяю его на своем Mac (www.10studio.tech), он всегда показывает старый сертификат.
Очистка истории браузера не помогает.
Может кто-нибудь подтвердить, что это не работает только для меня? И что я могу сделать?
Редактирование 1:
Я использую docker и nginx. В nginx и на sslforfree.com у меня есть следующий my_server_block.conf
.
server {
listen 3002;
absolute_redirect off;
root /app;
location = / {
rewrite ^(.*)$ https://$http_host/docs/introduction redirect;
}
location / {
try_files $uri $uri/ =404;
}
}
server {
listen 3001 ssl;
ssl_certificate /certs/whole.crt;
ssl_certificate_key /certs/private.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://localhost:3002;
proxy_redirect off;
proxy_set_header Host $host:$server_port;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Ssl on;
}
}
docker-compose.yml
:
version: "3"
services:
docusaurus:
image: bitnami/nginx:1.16
restart: always
volumes:
- ./build:/app
- ./certs:/certs:ro
- ./my_server_block.conf:/opt/bitnami/nginx/conf/server_blocks/my_server_block.conf:ro
ports:
- "3001:3001"
- "3002:3002"
nginx.conf
:
# На основе https://www.nginx.com/resources/wiki/start/topics/examples/full/#nginx-conf
# user www www; ## По умолчанию: nobody
worker_processes auto;
error_log "/opt/bitnami/nginx/logs/error.log";
pid "/opt/bitnami/nginx/tmp/nginx.pid";
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log "/opt/bitnami/nginx/logs/access.log";
add_header X-Frame-Options SAMEORIGIN;
client_body_temp_path "/opt/bitnami/nginx/tmp/client_body" 1 2;
proxy_temp_path "/opt/bitnami/nginx/tmp/proxy" 1 2;
fastcgi_temp_path "/opt/bitnami/nginx/tmp/fastcgi" 1 2;
scgi_temp_path "/opt/bitnami/nginx/tmp/scgi" 1 2;
uwsgi_temp_path "/opt/bitnami/nginx/tmp/uwsgi" 1 2;
sendfile on;
tcp_nopush on;
tcp_nodelay off;
gzip on;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_proxied any;
gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;
keepalive_timeout 65;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
include "/opt/bitnami/nginx/conf/server_blocks/*.conf";
# HTTP сервер
server {
# порт для прослушивания. Также может быть установлен на IP:PORT
listen 8080;
location /status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
}
}
Очевидная вещь – вам нужно перезагрузить/перезапустить ваш веб-сервер после обновления TLS сертификата.
Похоже, вы используете docker-compose, но ваши контейнеры не были обновлены, так как ваша версия nginx сообщает 1.9.4, в то время как вы, похоже, запрашивали 1.16.x. Рассмотрите возможность принудительного обновления с помощью чего-то вроде:
docker-compose up --force-recreate --build -d
Проверьте, что сертификаты в этом месте являются правильными сертификатами. Предполагая, что вы правильно перезапустили nginx и нет другой конфигурации, перезаписывающей вашу, nginx должен загружать сертификаты в этом месте. Возможно, вы поместили сертификаты в этот каталог на хостовой машине, а не в этот каталог внутри образа Docker?
Ответ или решение
Проблема: Сертификат SSL не обновляется
Когда ваш SSL сертификат истекает и вы устанавливаете новый, может возникнуть несколько сценариев, при которых веб-сервер продолжает показывать старый сертификат. Рассмотрим основные шаги и рекомендации для решения этой проблемы.
1. Перезагрузка NGINX
Первое, что следует сделать после обновления сертификатов — перезагрузить NGINX. Если вы используете Docker, необходимо убедиться, что контейнер, в котором запущен NGINX, обновлен с новыми сертификатами. В вашем случае, попробуйте выполнить:
docker-compose up --force-recreate --build -d
Это позволит принудительно пересоздать и перезапустить контейнеры с новыми конфигурациями и сертификатами.
2. Проверка местоположения сертификатов
Убедитесь, что ваш NGINX действительно использует правильные сертификаты. Проверьте пути к файлам сертификатов в вашей конфигурации my_server_block.conf
:
ssl_certificate /certs/whole.crt;
ssl_certificate_key /certs/private.key;
Убедитесь, что whole.crt
и private.key
находятся в директории /certs/
внутри вашего контейнера. Чтобы подтвердить это, вы можете открыть терминал контейнера:
docker exec -it <container_id> /bin/sh
И ввести команду для проверки содержимого каталога:
ls -l /certs/
3. Очистка кэша браузера
Вы уже упомянули, что очищали историю браузера, но иногда браузеры могут кэшировать сертификаты. Попробуйте открыть сайт в режиме инкогнито или используйте другой браузер для тестирования.
4. Проверка конфигурации NGINX
Проверьте, загружается ли конфигурационный файл my_server_block.conf
:
include "/opt/bitnami/nginx/conf/server_blocks/*.conf";
Убедитесь, что конфигурация корректная и что другие конфигурационные файлы не переопределяют настройки вашего server block
, где указаны сертификаты.
5. Логи NGINX
Если вышеописанные шаги не помогли, проверьте журналы ошибок NGINX для получения дополнительных сведений о возможных проблемах. Обычно журналы находятся по пути:
/opt/bitnami/nginx/logs/error.log
6. Проверка сервера
Иногда проблема может заключаться в кэшировании на стороне сервера или в промежуточных проксисерверах. Используйте команды типа curl
для проверки сертификата без использования браузера:
curl -Iv https://www.10studio.tech
Это позволит вам увидеть сертификат, который используется сервером.
Заключение
Несмотря на то что вы уверены в установке нового SSL сертификата, даже маленькая ошибка в конфигурации или процессе сборки контейнера может привести к тому, что старый сертификат будет продолжать отображаться. Следуя этим шагам, вы можете диагностировать и устранить проблему. Если проблема не решается, рассмотрите возможность получения дополнительной помощи от специалистов по сетевой безопасности или хостингу.