Cómo configurar el agrafado OCSP en Nginx y Apache

El agrafado OCSP (OCSP stapling) hace que sea el servidor web, y no el navegador, quien consulte a la autoridad de certificación si el certificado sigue siendo válido. El servidor guarda esa respuesta firmada y la adjunta al handshake TLS, así el cliente no tiene que hacer una consulta extra ni revelar a la CA qué sitio visita. En esta guía comprobarás si tu certificado admite OCSP, activarás el agrafado en Nginx y en Apache sobre Ubuntu 24.04 y verificarás que la respuesta llega al cliente.

Importante

Let's Encrypt dejó de incluir la URL OCSP en sus certificados y apagó sus responders OCSP en 2025; ahora publica la revocación solo mediante CRL. Con un certificado de Let's Encrypt no hay nada que agrafar y Nginx mostrará un aviso si activas ssl_stapling. Esta guía es útil para certificados de CA comerciales (DigiCert, Sectigo, GlobalSign y otras) que siguen publicando un responder OCSP.

Requisitos previos

Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath, con un usuario no root con privilegios sudo.
Nginx (1.24 en Ubuntu 24.04) o Apache (2.4.58) ya sirviendo tu dominio por HTTPS.
Un certificado emitido por una CA que publique un responder OCSP, con el certificado del servidor, la cadena intermedia y la clave privada en el servidor.
Salida HTTP (puerto 80) permitida desde el servidor hacia Internet, porque los responders OCSP funcionan sobre HTTP.

En los ejemplos se usan estas rutas; sustitúyelas por las tuyas:

/etc/ssl/your_domain/fullchain.pem: certificado del servidor seguido de los intermedios.
/etc/ssl/your_domain/chain.pem: solo los certificados intermedios de la CA.
/etc/ssl/your_domain/privkey.pem: clave privada.

Sustituye también your_domain por tu dominio real.

Paso 1: Comprobar que el certificado tiene un responder OCSP

El servidor solo puede agrafar si el certificado incluye la URL del responder OCSP en la extensión Authority Information Access. Extráela con openssl:

openssl x509 -in /etc/ssl/your_domain/fullchain.pem -noout -ocsp_uri

Si el certificado admite OCSP, verás una URL:

http://ocsp.digicert.com

Si el comando no imprime nada, el certificado no tiene responder OCSP (es el caso de los certificados actuales de Let's Encrypt) y no tiene sentido seguir con esta guía para ese certificado.

Opcionalmente, consulta tú mismo el responder para confirmar que responde y que el certificado está en estado good. openssl ocsp necesita el certificado del servidor por separado, así que extrae el primero de fullchain.pem:

openssl x509 -in /etc/ssl/your_domain/fullchain.pem -out /tmp/cert.pem

openssl ocsp -issuer /etc/ssl/your_domain/chain.pem -cert /tmp/cert.pem \
  -url "$(openssl x509 -in /tmp/cert.pem -noout -ocsp_uri)" \
  -CAfile /etc/ssl/certs/ca-certificates.crt -verify_other /etc/ssl/your_domain/chain.pem

Response verify OK
/tmp/cert.pem: good
	This Update: Sep 24 08:12:00 2026 GMT
	Next Update: Oct  1 07:27:00 2026 GMT

Si chain.pem contiene varios intermedios, el emisor directo del certificado debe ser el primero del archivo.

Paso 2: Activar el agrafado OCSP en Nginx

Nginx descarga la respuesta OCSP en segundo plano y la guarda en memoria. Necesita tres cosas: activar el agrafado, un archivo con la cadena de confianza para verificar la respuesta y un resolver DNS para encontrar el host del responder.

Abre el bloque server HTTPS de tu sitio:

sudo nano /etc/nginx/sites-available/your_domain

Añade las directivas de agrafado dentro del bloque server que escucha en el puerto 443:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name your_domain;

    ssl_certificate     /etc/ssl/your_domain/fullchain.pem;
    ssl_certificate_key /etc/ssl/your_domain/privkey.pem;

    # Agrafado OCSP
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/ssl/your_domain/chain.pem;

    # DNS usado por Nginx para resolver el host del responder OCSP
    resolver 127.0.0.53 valid=300s;
    resolver_timeout 5s;

    # ... resto de la configuración del sitio
}

Qué hace cada directiva:

ssl_stapling on: activa la descarga y el envío de respuestas OCSP.
ssl_stapling_verify on: Nginx verifica la firma de la respuesta antes de enviarla, usando los certificados de ssl_trusted_certificate.
ssl_trusted_certificate: cadena de la CA (intermedios, y la raíz si la CA firma la respuesta con ella). No se envía a los clientes.
resolver: 127.0.0.53 es el resolver local de systemd-resolved en Ubuntu. Si no lo usas, pon la IP de tu servidor DNS.

Comprueba la sintaxis y recarga Nginx:

sudo nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

sudo systemctl reload nginx

Si nginx -t muestra "ssl_stapling" ignored, no OCSP responder URL in the certificate, el certificado no tiene URL OCSP (vuelve al paso 1).

Nota

Nginx pide la respuesta OCSP la primera vez que un cliente se conecta tras arrancar o recargar, así que esa primera conexión en cada proceso worker llega sin respuesta agrafada. Es normal: repite la prueba del paso 4 un par de veces.

Paso 3: Activar el agrafado OCSP en Apache

Apache necesita una caché compartida para las respuestas OCSP. Esa caché (SSLStaplingCache) solo se puede definir en el contexto global, fuera de cualquier VirtualHost, y depende del módulo socache_shmcb.

Activa los módulos necesarios:

sudo a2enmod ssl socache_shmcb

Crea un archivo de configuración global para la caché:

sudo nano /etc/apache2/conf-available/ocsp-stapling.conf

SSLStaplingCache "shmcb:/var/run/apache2/ssl_stapling(128000)"
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off

SSLStaplingResponderTimeout: segundos de espera máxima al responder OCSP.
SSLStaplingReturnResponderErrors off: si el responder devuelve un error, Apache no se lo pasa al cliente; simplemente no agrafa.

Actívalo:

sudo a2enconf ocsp-stapling

Ahora abre el VirtualHost HTTPS de tu sitio:

sudo nano /etc/apache2/sites-available/your_domain-ssl.conf

Añade SSLUseStapling on junto a la configuración de certificados:

<VirtualHost *:443>
    ServerName your_domain

    SSLEngine on
    SSLCertificateFile    /etc/ssl/your_domain/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/your_domain/privkey.pem

    SSLUseStapling on

    # ... resto de la configuración del sitio
</VirtualHost>

Desde Apache 2.4.8, SSLCertificateFile puede contener el certificado y los intermedios, así que SSLCertificateChainFile ya no hace falta. Apache necesita que el intermedio esté presente para saber a quién preguntar y cómo verificar la respuesta.

Comprueba la configuración y recarga:

sudo apache2ctl configtest

Syntax OK

sudo systemctl reload apache2

Paso 4: Verificar que el servidor envía la respuesta OCSP

El cliente pide la respuesta agrafada con la extensión status_request del handshake. En openssl s_client esa petición se activa con -status:

openssl s_client -connect your_domain:443 -servername your_domain -status < /dev/null 2>/dev/null | sed -n '/OCSP response/,/Cert Status/p'

Con el agrafado funcionando verás una respuesta firmada y el estado del certificado:

OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    ...
    Cert Status: good

Si en su lugar aparece esto, el servidor todavía no ha agrafado nada:

OCSP response: no response sent

En Nginx es normal en las primeras conexiones tras recargar; repite el comando unos segundos después. Si persiste, revisa la sección de solución de problemas.

Solución de problemas

no response sent de forma permanente. Revisa el log de errores del servidor web, donde Nginx y Apache registran los fallos al contactar con el responder:

sudo tail -n 50 /var/log/nginx/error.log

sudo tail -n 50 /var/log/apache2/error.log

OCSP responder timed out o errores de conexión. El servidor no llega al responder. Comprueba la resolución DNS y la salida por el puerto 80:

curl -sI "$(openssl x509 -in /etc/ssl/your_domain/fullchain.pem -noout -ocsp_uri)" | head -n 1

Cualquier respuesta HTTP (aunque sea 400 o 405) indica que hay conectividad. Si no hay respuesta, revisa el firewall de salida o el resolver configurado.

OCSP_basic_verify() failed en Nginx. El archivo de ssl_trusted_certificate no contiene la cadena correcta. Asegúrate de que incluye el intermedio que emitió tu certificado y, si la CA lo requiere, su raíz.

no OCSP responder URL in the certificate. El certificado no admite OCSP. Quita ssl_stapling / SSLUseStapling para ese sitio; no aporta nada.

Conclusión

Has comprobado que tu certificado publica un responder OCSP, has activado el agrafado en Nginx o Apache y has verificado con openssl s_client -status que el servidor entrega una respuesta válida. Así los clientes validan la revocación sin consultas adicionales a la CA. Como siguientes pasos, puedes endurecer la configuración TLS del servidor (TLS 1.2 y 1.3, cifrados modernos), añadir la cabecera HSTS y revisar el resultado en SSL Labs.

En esta página