You will need to RELOAD Nginx in order for the renewed certificates to display the correct expiration date (read the clarification below and the other comments for an explanation of the difference between RELOADING and RESTARTING Nginx).
After reloading Nginx, a simple cache-clearing and browse should allow you to view this the updated expiration dates on the SSL cert.
Or if you prefer cli, you could always use the old trusty OpenSSL command:
echo | openssl s_client -connect your.domain.com:443 | openssl x509 -noout -dates
That would give you the current dates on the certificate.
In your case the port would be 80 instead of 443 (it was later stated by OP that the ports 80 in the question should have actually been 443, but Nginx will listen on HTTP or HTTPS on whatever ports you give it, as long as they are not currently in use by another process).
Many times nginx -s reload does not work as expected. On many systems (Debian, etc.), you would need to use /etc/init.d/nginx reload.
Edit to update and clarify this answer:
On modern systems with systemd, you can also run systemctl reload nginx or service nginx reload.
All of these reload methods are different from restart by the fact that they send a SIGHUP signal that tells Nginx to reload its configuration without killing off existing connections (which would happen with a full restart and would almost certainly be user-impacting).
If for some reason, Nginx does not reload your certificate, you can restart it, but note that it will have much more of an impact than reload.
To restart Nginx, you would simply run systemctl restart nginx, or on systems without systemd, you would do nginx -s stop && nginx -s start.
If all else fails (for whatever reason), just kill the Nginx PID(s), and you can always start it up manually by specifying the configuration file directly using nginx -c /path/to/nginx.conf.
This question is old and this is not a real answer, but I had the same problem. In dpi/https.c, I commented out the dialogue box code after
case X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN:
and then changed
response_number = dialogue_get_answer_number();
to
response_number = 1;
I'm sure this is terrible for some reason, but I would always agree with the dialogue box anyway.
Best Answer
The real fix for this is to ensure that your server presents all certificates in the chain and not just the end-entity (server) certificate.
Point your server administrator to RFC 5246 Section 7.4.2 which clearly states that This message conveys the server's certificate chain to the client.
If your admin refuses/can't do this for some reason, your alternative option is to try and get
curlto work with the malformed handshake.According to a message on the Curl mailing list:
You should be able to add the Root CA and all intermediates certificates to a bundle and point
curlto it using the--cacert <file>option.As your browsers work, you can access the correct CA certificates from there. On the certificates tab (different for each browser, but I'm sure you'll figure that one out), view the certificate chain. Double-click the Root CA first Globalsign Root CA - G1 and on the Details tab, click on Copy to file.... Save it as
root.cer. Do the same with the AlphaSSL CA - SHA256 - G2 and save it asissuing.cer. Join the two together in a single file (e.g.chain.cer) and use that as the argument to-cacert.As kindly pointed out by @A.B. the missing certificate can also be found here.
Your browsers work because they cache CA certificates. If you've navigated to a correctly configured website at some point in the past, whose certificate was issued by the same CA as your server's certificate, it will be cached by the browser. When you subsequently visit your incorrectly configured site, your browser will use the CA certificates in its cache to build the chain. To you, it seems like everything is fine, although behind the scenes, the server is mis-configured.
Note that on Windows, IE/Edge and Chrome share the same cache, while Firefox uses its own.
In addition to the above, IE/Edge and Chrome (as they share the same crypto stack) will use an extension within certificates called the AuthorityInformationAccess. This has a caIssuer option which provides a URL from which the end-entity certificate's CA certificate can be downloaded. Therefore, even if one of these browsers hasn't cached the missing certificates from previous browsing, it can fetch it if required. Note that Firefox doesn't do this, which is why sometimes Firefox can show certificate errors when IE/Edge and Chrome seem to work.