Ssl stapling failing on reboot

My web server is (include version):
nginx 18.0.0

The operating system my web server runs on is (include version):
ubuntu 20.04 (x64 raspberry pi 4)

I can login to a root shell on my machine (yes or no, or I don’t know):
yes

Hi,
Not sure if anyone can help…
I’ve noticed that after a reboot if I check the status of nginx i get the error nginx: [warn] “ssl_stapling” ignored, host not found in OCSP responder “ocsp.int-x3.letsencrypt.org” in the certificate…"
I have the resolver IP address set, and the ssl_trusted_certificate set to chain.pem in my domains live folder of lets encrypt.
If I restart nginx and check the status it starts with no errors.
Does anyone have any ideas? (I’m far from an expert :slight_smile:)
Thanks in advance.

1 Like

Hi @ad84,

What’s your resolver IP?

Have you tried to use dig ocsp.int-x3.letsencrypt.org @your resolver IP?

Can you try to see if the below fix works? (It’s just a bunch of checks)

By the way, I’m not sure if that’s a valid assumption, but double check your Nginx systemd file to make sure it starts after networking.
https://www.nginx.com/resources/wiki/start/topics/examples/systemd/

Thanks

1 Like

Thanks for the reply.

I have the IPs set to my local DNS (another pi4) and my ISPs as backup. I’ve tried 8.8.8.8 too. Was set to itself 127.0.0.1 originally, which also works but not after a reboot.
I’d not tried the dig you suggested but have now and it gives an answer.

I’ll check you last link about starting after networking; I’m very new to all this, 6 months linux/pi - I’ll see what i can find out :slight_smile:

1 Like

Hi I checked the link: https://www.nginx.com/resources/wiki/start/topics/examples/systemd/

I assume the “After=syslog.target network-online.target remote-fs.target nss-lookup.target” is the part instructing nginx to start after networking…
i ran:
cat /lib/systemd/system/nginx.service | grep After
and got the output:
After=network-online.target remote-fs.target nss-lookup.target
I guess this is instructing the same thing?

The only thing i haven’t tried is to extend the resolver timeout more? I have 10s set at the moment.

Thanks again for the help.

1 Like

Hi,

I also don’t have much Linux knowledge at this part, but I think it probably will work.

Can you try to remove the 10s timeout completely? (Just remove timeout interval)

1 Like

Thanks for the reply.
I’ve removed the timeout and it still throws the error after a reboot.
nginx still starts and I dont often reboot and very rarely get a power cut to force one so i may have to live with it.
Seems to be a pi problem (or maybe my router?) rather than ubuntu/nginx. I’ve just tired my other pi running nginx 1.14.2 on raspberry os and it does the same.

1 Like

Hi,

Then i’m not quite sure what’s the reason, sorry.

In that case, try to only restart nginx (don’t restart your Pi) and see if that still gives an error.

1 Like

Hi,
Thanks for the help.
Restarting nginx never gives the error. The error is only there the fist time nginx starts on after a reboot.

1 Like

I think this is a bug in nginx and/or your default systemd configuration but it’s possible that people on this forum don’t have the right expertise to diagnose it, unfortunately. You might be able to get more ideas from a different forum.

A workaround without solving the problem might be to create another startup task, or recurring task, to restart nginx once soon after each reboot.

4 Likes

Thanks for the reply.
I went with your work around idea - set a cron job to run as root seemed the easiest:
@reboot sleep 30 && sudo service nginx restart
This works fine.
Without the time delay it doesn’t work. You could most probably get away with less time, I’ve not tried :slight_smile:.

2 Likes

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