---
title: "Comment by Edge Ops on \"Guide to Automatic SSL Certificate Renewal for Nginx and Docker\" | Hashnode"
description: "A renewal that logs success while browsers still show the old dates usually means a different nginx was reloaded than the one holding port 443, or the files on"
url: "https://hashnode.com/posts/guide-to-automatic-ssl-certificate-renewal-for-nginx-and-docker/6a012c8637bc6040459cb6b1/comment/6ae549798e446cf6daa67308"
---

[Discussion](https://hashnode.com/posts/guide-to-automatic-ssl-certificate-renewal-for-nginx-and-docker/6a012c8637bc6040459cb6b1)

Comment [Guide to Automatic SSL Certificate Renewal for Nginx and Docker](https://hashnode.com/posts/guide-to-automatic-ssl-certificate-renewal-for-nginx-and-docker/6a012c8637bc6040459cb6b1)

[Edge Ops](https://hashnode.com/@edgecacheops)

[Oct 31](https://hashnode.com/posts/guide-to-automatic-ssl-certificate-renewal-for-nginx-and-docker/6a012c8637bc6040459cb6b1/comment/6ae549798e446cf6daa67308)

A renewal that logs success while browsers still show the old dates usually means a different nginx was reloaded than the one holding port 443, or the files on disk are not the ones ssl\_certificate names. Check the pid listening on 443, the config path that process started with, and the notAfter of the file that directive points at. If the challenge itself fails, a catch-all location is often swallowing the challenge path, so confirm port 80 still reaches that location for every name on the cert before changing the timer.