SSL y Ngnix: no se define "ssl_certificate" en el servidor que escucha en el puerto SSL durante el protocolo de enlace SSL


23

Logré crear mis certificados con LE sin errores, también logré redirigir mi tráfico desde el puerto 80 al puerto 443. Pero cuando vuelvo a cargar mi servidor nginx no puedo acceder a mi sitio web. Los registros de errores de Ngnix muestran esta línea:

4 no "ssl_certificate" is defined in server listening on SSL port while SSL handshaking, client: 192.168.0.104, server: 0.0.0.0:443

Creo que esto significa que no puede encontrar los certificados que luego navegué a la ruta de los certificados y ambos están allí, ¿cuál podría ser el problema? Así es como se ve mi configuración de Ngnix:

server {
       listen         80;
       server_name    pumaportal.com www.pumaportal.com;
       return         301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;

    server_name pumaportal.com www.pumaportal.com;

    add_header Strict-Transport-Security "max-age=31536000";

    ssl_certificate /etc/letsencrypt/live/pumaportal.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/pumaportal.com/privkey.pem;

    ssl_stapling on;
    ssl_stapling_verify on;

    access_log /var/log/nginx/sub.log combined;

    location /.well-known {
       alias /[MY PATH]/.well-known;
    }

    location / {
        proxy_pass http://localhost:2000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header X-Forwarded-For $remote_addr;
    }

}

Todo parece bastante sencillo, no entiendo dónde podría estar el problema.

Después de ejecutar nginx -t todo parece estar bien:

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

¿Tienes otros serverbloques? ¿Qué hiciste exactamente cuando recibiste ese error?
Tero Kilkanen

1
¿El usuario nginx tiene acceso al archivo de certificado y al archivo de clave? No es suficiente tener acceso de lectura a los archivos, el usuario también necesita tener permisos de lectura y ejecución para todos los directorios de la cadena al archivo.
Jenny D dice Reinstate Monica el

Respuestas:


25

Supongo que tiene otro servidor escuchando en el puerto 443. Este servidor no tiene definido ssl_certificate, y se selecciona automáticamente (SNI). Intente eliminar todos los enlaces simbólicos de / etc / nginx / sites habilitado, excepto este servidor que desea que funcione (si es posible, de lo contrario, verifique todos sus servidores para escuchar 443 sin estar configurado correctamente).


2
¡BINGO! En mi caso, creo un archivo de configuración para vhost mail.mydomain, para poder construir un certificado LE para mi instalación de palomar y olvidé agregar el archivo de configuración.
Marcos Regis

7

Solucioné este mismo problema más temprano esta mañana, así que estoy aquí para aclarar el punto de CA (que, ahora que entiendo el problema, estaba bien hecho), lo más probable es que tenga dos bloques de servidor:

# defecto
servidor {
    escuchar 443 default_server; # Tenga en cuenta la falta de `ssl`
    nombre del servidor _;
    # ...
}

#real site
servidor {
    escuchar 443 ssl;
    nombre del servidor ;
    # ...
}

SNI solo coincidirá con aquellos que están etiquetados con un ssloyente. Sin embargo, el servidor predeterminado capturará todo el tráfico entrante en 443, independientemente de SSL o no. Por lo tanto, en realidad está evitando que SNI realmente funcione, desde el primer momento, al atesorar todo el tráfico por sí mismo.

Síntomas

  • Parecerá que nginx no está cargando su configuración (incluso con una nginx -ty una recarga de servicio)
  • Errores que indican "no se encontró ssl_certificate en el bloque del servidor"
  • nginx solo aplica su host al oyente 443 predeterminado.

Soluciones:

Solucioné el problema esta mañana eliminando el bloqueo predeterminado del servidor, permitiendo así que SNI coincida con los oyentes SSL.

Una solución alternativa sería agregar el ssloyente y las ssl_certificatelíneas al bloque del servidor para que SNI esté esencialmente habilitado en su host predeterminado. Aún obtendrá errores de SSL, por lo que no es la mejor solución, pero permitirá que su SNI funcione :)


5

Debe definir un solo default_serverparámetro en la configuración de nginx.

Solicite default_serverya sea example.com o www.example.com. No ambos.

Por lo tanto, esto funcionará:

server {
    listen 443 ssl;
    listen 80;

    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 80 default_server;

    server_name www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl default_server;

    server_name www.example.com;
    root /var/www/example.com/public;
    index index.php index.html index.nginx-debian.html;

    ssl on;
    ssl_certificate /etc/ssl/chain.crt;
    ssl_certificate_key /etc/ssl/examplecom.key;

    (rest of your nginx config goes here....)
}

Nota sobre hosts virtuales: asegúrese de que el default_serverparámetro no esté definido en ningún otro lugar, si tiene varios hosts en el servidor.


muy agradable SSL en esta trabajando para mí
Josua Marcel Chrisano

1

Tarde al juego como de costumbre, pero como me ayudó ... Verifique si el certificado está mal formado. Al construir el CRT "unificado" (CRT + intermedio), haciendo

$cat server.crt provider.intermediate > unified.crt

De alguna manera perdí un LF y obtuve una línea como esta:

-----END CERTIFICATE----------BEGIN CERTIFICATE-----

en lugar de

-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----

y nginx no tomaría el certificado y fallaría con el error mencionado anteriormente.

Obra

# openssl x509 -in unified.cert -text -out

me dio la pista para openssl sería un error.


-1

Compruebe si sus permisos de archivo para los certificados son correctos. Por favor, publique el listado del directorio ( ls -la)

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.