"ssl_stapling" ignored, no OCSP responder URL in the certificate

I have “ssl_stapling” ignored, no OCSP responder URL in the certificate erros in /var/log/nginx

Is this an issue?

I am having issues when issuing SSL certificates

Error: Let’s Encrypt validation status 400 (mail.domain.pro). Details: 403:“111.11.111.111: Invalid response from http://mail.domain.pro/.well-known/acme-challenge/2KFlR4pfSmpUJthMSK_v3rRIsgBADU8Z5bpCE24gcgU: 404”

These errors are for domains that have been running on the server form last 4 months. We have around 300-400 domains on the server.

1 Like

Suggest try the various threads here: Search results for 'ocsp order:latest_topic' - Hestia Control Panel - Discourse

Check max open files ..

Probally to low ..

No, it isn’t. Let’s Encrypt has removed the OCSP URLs from their certificates, but most of the templates in Hestia still use the directive ssl_stapling on;. That’s why you’re seeing the warning but there’s no need to worry about it.

Regarding open files… I’ve written a small script that checks the current files used by Nginx and Apache2 processes and compares them with the current soft limits assigned to each process. If the number of open files exceeds the defined threshold (80% by default), it will display the count in red.

Text example:

❯ curl -fsSLm10 https://7j.gg/chknof | sudo bash -s --
Checking services nginx apache2
The open files limit threshold has been set at 80%

Process 1936 :: /usr/sbin/apache2 -k start
Current open files:   85
Limit for open files: 8192

Process 21887 :: /usr/sbin/apache2 -k start
Current open files:   84
Limit for open files: 8192

Process 21890 :: /usr/sbin/apache2 -k start
Current open files:   92
Limit for open files: 8192

Process 21892 :: /usr/sbin/apache2 -k start
Current open files:   92
Limit for open files: 8192

Process 1840 :: nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
Current open files:   53
Limit for open files: 1024

Process 22082 :: nginx: worker process
Current open files:   56
Limit for open files: 65535

Process 22083 :: nginx: worker process
Current open files:   56
Limit for open files: 65535

Process 22084 :: nginx: worker process
Current open files:   56
Limit for open files: 65535

Process 22085 :: nginx: cache manager process
Current open files:   53
Limit for open files: 65535

Screenshot examples:

Open files do not seem to be an issue. I increase the limits a while back when I had the same exact issue.

curl -fsSLm10 https://7j.gg/chknof | sudo bash -s –

Checking services nginx apache2
The open files limit threshold has been set at 80%

Process 3797068 :: /usr/sbin/apache2 -k start
Current open files: 1794
Limit for open files: 8192

Process 3797135 :: /usr/sbin/apache2 -k start
Current open files: 1792
Limit for open files: 8192

Process 3797390 :: /usr/sbin/apache2 -k start
Current open files: 1801
Limit for open files: 8192

Process 3797741 :: /usr/sbin/apache2 -k start
Current open files: 1801
Limit for open files: 8192

Process 3797911 :: /usr/sbin/apache2 -k start
Current open files: 1801
Limit for open files: 8192

Process 3508133 :: nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
Current open files: 1670
Limit for open files: 262144

Process 3811240 :: nginx: worker process
Current open files: 1664
Limit for open files: 262144

Process 3811241 :: nginx: worker process
Current open files: 1663
Limit for open files: 262144

Process 3811242 :: nginx: worker process
Current open files: 1663
Limit for open files: 262144

Process 3811243 :: nginx: worker process
Current open files: 1662
Limit for open files: 262144

Process 3811244 :: nginx: worker process
Current open files: 1660
Limit for open files: 262144

Process 3811245 :: nginx: worker process
Current open files: 1660
Limit for open files: 262144

Process 3811246 :: nginx: worker process
Current open files: 1660
Limit for open files: 262144

Process 3811247 :: nginx: worker process
Current open files: 1660
Limit for open files: 262144

Process 3811248 :: nginx: worker process
Current open files: 1660
Limit for open files: 262144

Process 3811249 :: nginx: worker process
Current open files: 1660
Limit for open files: 262144

Process 3811250 :: nginx: worker process
Current open files: 1660
Limit for open files: 262144

Process 3811251 :: nginx: worker process
Current open files: 1660
Limit for open files: 262144

Process 3811252 :: nginx: worker process
Current open files: 1660
Limit for open files: 262144

Process 3811253 :: nginx: worker process
Current open files: 1660
Limit for open files: 262144

Process 3811254 :: nginx: worker process
Current open files: 1660
Limit for open files: 262144

Process 3811255 :: nginx: worker process
Current open files: 1660
Limit for open files: 262144

Process 3811256 :: nginx: cache manager process
Current open files: 1641
Limit for open files: 262144

v-add-letsencrypt-domain inquire domain.com ‘’ yes

Error: Let’s Encrypt validation status 400 (mail.domain.com). Details: 403:“111.111.1.111: Invalid response from http://mail.domain.com/.well-known/acme-challenge/LYvCgsx8EJKdMrtPp5cQzFQMs3CrZ7FgQ981MNi3Q4I: 404”

Checked on Let’s debug and all good here: All OK!

OK

No issues were found with mail.domain.com. If you are having problems with creating an SSL certificate, please visit the Let’s Encrypt Community forums and post a question there.

1 Like

In this case it’s important to share the actual domain name.

So this has been happening for multiple domains and once I change the IP for a domain, the issue is resolved.

So you have multiple public IPs in your server and it only works with some of them?

it seems let’s encrypt ends OCSP support. consequently OCSP stapling must be disabled in nginx:

  • January 30, 2025
    • OCSP Must-Staple requests will fail, unless the requesting account has previously issued a certificate containing the OCSP Must Staple extension
  • May 7, 2025
    • Prior to this date we will have added CRL URLs to certificates
    • On this date we will drop OCSP URLs from certificates
    • On this date all requests including the OCSP Must Staple extension will fail
  • August 6, 2025
    • On this date we will turn off our OCSP responders

I guess that In nginx.ssl.conf of your domains, ssl stapling should be turned off or commented out but if domains are rebuilt it will put ssl stapling on. change should be at hestia cp level:

To do so for all domains,
it would be required to go to nginx templates of Hestia under:
/usr/local/hestia/data/templates/web/nginx
choose the .stpl that are used for your domains. (in fact, you should do it with all templates where you find the two directives below.
Comment out like this:
# ssl_stapling on;
# ssl_stapling_verify on;

save
Rebuild all domains of hestia users by doing v-rebuild-web-domains USER
restart nginx
errors should be gone in error.log

I have created a ticket for this:

Keep in mind that these are not actual errors, just warnings. Your site has SSL Stapling enabled, so Nginx tries to check the certificate but the OCSP URL doesn’t exist, which results in a log notification. Your sites will work as expected, no problem at all.

As you said, to avoid the warning in the logs, the templates should be modified and the sites rebuilt. However, keep in mind that Let’s Encrypt isn’t the only CA out there, other CAs still use OCSP, so SSL Stapling remains valid for those certificates.

That said, to avoid confusion, and because I’d guess more than 90% of users (made-up percentage :grinning_face_with_smiling_eyes:) use Let’s Encrypt, it might be a good idea to comment out the SSL Stapling directives in all templates.

Ideally, there would be an option to enable or disable SSL Stapling when adding the certificate, but that’s another battle.

Until the devs decide whether to comment out SSL Stapling in the templates (if they agree I can add a PR), you can use this script to modify them all and rebuild every user’s mail and web domains.

curl -fsSLm10 https://7j.gg/remstap | sudo bash -s --

This is the script:

#!/usr/bin/env bash
set -euo pipefail
ARG="${1:-}"

if [[ $EUID -ne 0 ]]; then
    echo "Error: you must be root to execute this script" >&2
    exit 1
fi

if [[ -t 1 ]]; then
    GC=$(tput setaf 34)
    YC=$(tput setaf 226)
    BC=$(tput setaf 27)
    OC=$(tput setaf 198)
    RC=$(tput setaf 1)
    NC=$(tput sgr0)
else
    echo "Error: This script must be run interactively" >&2
    exit 2
fi

BIN="/usr/local/hestia/bin"
DIRS="/usr/local/hestia/data/templates/ /usr/local/hestia/nginx/"
INUSEDIRS="/etc/nginx/conf.d/domains/ /usr/local/hestia/nginx/"
BCKDIR="/root/backup_hestia_templates_$(date +'%Y-%-m-%d_%H%M')"

set +o pipefail
# shellcheck disable=SC2086
NINUSE="$(grep -REl '^\s*ssl_stapling.*on;' $INUSEDIRS | wc -l)"
set -o pipefail
if [[ $NINUSE -eq 0 ]]; then
    echo "I didn't found any conf file using ssl stapling."
    if [[ "$ARG" != "-f" ]]; then
        echo "If you still want to modify the templates and rebuild your sites, use ${YC}-f${NC} argument"
        exit
    else
        echo
        echo "${YC}Forcing execution...${NC}"
        echo
    fi
fi

echo "I've found ${YC}${NINUSE}${NC} configuration files using SSL stapling."
echo "I'll remove SSL stapling from templates and rebuild web and mail domains. ${OC}This may take a few minutes${NC}."
echo "Note: All modified files will be backed up in the ${BC}${BCKDIR}/${NC} directory."
echo

read -r -p "Do you want to continue? [y/N] " response </dev/tty
response=${response,,}

if [[ "$response" != "y" ]]; then
    echo "Aborting script."
    exit 1
fi
echo
echo -n "Modifying templates and conf: "
# shellcheck disable=SC2086
grep -rEl '^\s*ssl_stapling.*on.*' $DIRS | while read -r file; do
    mkdir -p "${BCKDIR}$(dirname "$file")"
    cp "$file" "${BCKDIR}$file"
    sed -i -E '
    0,/^\s*ssl_stapling/ {
      /^\s*ssl_stapling/ {
        s/^(\s*)(ssl_stapling.*)/\1\#Commented out ssl_stapling directives due to Lets Encrypt ending OCSP support in 2025\n\1#\2/
        b
      }
    }
    /^\s*ssl_stapling/ s/^(\s*)/\1#/
    /^\s*ssl_stapling_verify/ s/^(\s*)/\1#/
  ' "$file"
done
echo "${GC}Done${NC}"

for user in $("$BIN"/v-list-users plain | cut -f1 | sort); do
    echo "Rebuilding web and mail domains for user ${GC}${user}${NC}"
    if "$BIN"/v-rebuild-web-domains "$user" &>/dev/null; then
        echo "  Web domains:  ${GC}OK${NC}"
    else
        echo "  Web domains:  ${RC}FAIL${NC}"
    fi
    if "$BIN"/v-rebuild-mail-domains "$user" &>/dev/null; then
        echo "  Mail domains: ${GC}OK${NC}"
    else
        echo "  Mail domains: ${RC}FAIL${NC}"
    fi
done

echo
if /usr/sbin/nginx -t &>/dev/null; then
    echo "Restarting nginx..."
    if systemctl restart nginx &>/dev/null; then
        echo "${GC}Nginx has been restarted${NC}"
    else
        echo "${RC}Error restaring nginx${NC}"
    fi
else
    echo "Seems ${RC}Nginx has some conf issues${NC}, check it, I won't try to restart the service."
    echo "These are the issues:"
    /usr/sbin/nginx -t
fi

It think is is more than 99% …

3 Likes