Connection refused while requesting certificate status

Help
1

My Nginx logs are full of these entries. It’s been happening for week now.

2019/12/09 08:13:00 [error] 49607#0: kevent() reported about an closed connection (61: Connection refused) while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, peer: [2600:1404:400::687c:3d19]:80, certificate: “/etc/ssl/cert/example.com/example.com”

The certificates renew just fine via cron. Nothing is blocked in my PF firewall.

I’m using Nginx with OCSP stapling enabled. Any ideas where to start looking?

2

Hi @Mayhem,

Welcome to the community forum!

Can you post the domain you’re attempting to check OCSP for?

3

Sorry, the domain is hzwb.com

4

I’m still receiving these errors this morning. Does anyone have any idea how to solve this?

5

What happens if you run “curl -v http://ocsp.int-x3.letsencrypt.org/” from a terminal?

What are Nginx’s resolver settings set to?

Does Nginx log what IP it’s trying to connect to?

1 Like
6 
$ curl -v http://ocsp.int-x3.letsencrypt.org/
*   Trying 2600:1404:400::687c:3d19:80...
* TCP_NODELAY set
* Connected to ocsp.int-x3.letsencrypt.org (2600:1404:400::687c:3d19) port 80 (#0)
> GET / HTTP/1.1
> Host: ocsp.int-x3.letsencrypt.org
> User-Agent: curl/7.67.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx
< Content-Length: 0
< Cache-Control: max-age=4351
< Expires: Wed, 11 Dec 2019 18:10:05 GMT
< Date: Wed, 11 Dec 2019 16:57:34 GMT
< Connection: keep-alive
< 
* Connection #0 to host ocsp.int-x3.letsencrypt.org left intact

Nginx settings:

ssl_certificate /etc/ssl/hzwb.crt;
ssl_certificate_key /etc/ssl/hzwb.key;
ssl_trusted_certificate /etc/ssl/hzwb.ca;

ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 [2001:4860:4860::8888] [2001:4860:4860::8844] valid=300s;
resolver_timeout 5s;

Nginx logs :

2019/12/11 08:14:34 [error] 71885#0: OCSP responder prematurely closed connection while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, peer: 104.124.58.154:80, certificate: "/etc/ssl/hzwb.crt"

2019/12/11 08:15:55 [error] 1636#0: OCSP responder timed out (60: Operation timed out) while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, peer: [2600:1404:400::687c:3d0b]:80, certificate: "/etc/ssl/hzwb.crt"
7

How often do you see errors? Constantly? Frequently? Occasionally?

Maybe try removing “valid=300s”? Forcing records to be cached up to 5 minutes longer than intended by the CDN might exacerbate occasional issues. (Though I’d be surprised if it made a big difference – CDNs have to plan around that anyway.)

8

I’ve been seeing these errors daily for a week or so. This just started up out of nowhere. I’ve been using the SSL certs without issues for sometime now.

I’ll try removing the “valid” off the config and see if that makes any difference.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

11

This issue can be caused by a mandatory access control mechanism (MAC, such as SELinux) that restricts your Nginx process from establishing connections to port 80.

For example, Fedora and RHEL/CentOS come with SELinux enabled by default and there the (counterintuitively named) SELinux boolean httpd_graceful_shutdown controls whether Nginx (or any other web-server) is allowed to connect to port 80.

Since Fedora 27 (and thus RHEL 8 I presume), httpd_graceful_shutdown is disabled, by default. Thus, one has to explicitly enable it (e.g. with setsebool) when OCSP stapling is configured in Nginx.

When it’s disabled on Fedora, Nginx logs subsequent OCSP errors like this:

2020/08/20 22:00:04 [crit] 39288#0: connect() to [2a02:26f0:eb::214:bd5a]:80
    failed (13: Permission denied) while requesting certificate status,
    responder: ocsp.int-x3.letsencrypt.org,
    peer: [2a02:26f0:eb::214:bd5a]:80,
    certificate: "/etc/pki/tls/certs/example.org.crt"

(with SELinux, there is also a name_connect AVC logged by the system)

Note that my example differs slightly from yours, i.e. different syscall and errno value. Thus, it looks like you are using a different OS with perhaps another MAC security mechanism.

See also: related thread with some more details in the Fedora Discourse instance

5 Likes