Estoy tratando de configurar SSL en mi servidor web apache2, pero parece que no funciona en absoluto.

He seguido un tutorial para crear archivos cert con openssl y los configuré /etc/apache2/sites-available/default-ssl.confcorrectamente.

Cada vez que intento abrir mi sitio web con https, mi navegador se niega a conectarse debido a problemas de seguridad. Dice que no he configurado mi sitio web correctamente.

En mi /var/log/apache2/error.logrecibo advertencias, que dicen que el certificado de mi servidor no incluye una ID que coincida con el nombre del servidor.

[Mon Apr 10 11:03:24.041813 2017] [mpm_prefork:notice] [pid 1222] AH00169: caught SIGTERM, shutting down
[Mon Apr 10 11:03:30.566578 2017] [ssl:warn] [pid 661] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Mon Apr 10 11:03:31.579088 2017] [ssl:warn] [pid 1194] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Mon Apr 10 11:03:31.592958 2017] [mpm_prefork:notice] [pid 1194] AH00163: Apache/2.4.25 (Raspbian) OpenSSL/1.0.2k configured -- resuming normal operations
[Mon Apr 10 11:03:31.593136 2017] [core:notice] [pid 1194] AH00094: Command line: '/usr/sbin/apache2'

¿Tienes alguna idea sobre cómo resolver esto? Gracias en lo que respecta!

Bien, noté que esta publicación se ve con bastante frecuencia recientemente, por lo que parece que muchas personas enfrentan el mismo problema que yo. Si es así, esto podría ayudarte.

He seguido un sencillo tutorial paso a paso para crear una certificación SSL para mi servidor web. Al igual que muchos tutoriales, el resultado del tutorial que seguí fue un certificado autofirmado con OpenSSL. Sí , autofirmado , ese era el problema. El navegador no podía confiar en el servidor debido a su certificado firmado por él mismo. Bueno, yo tampoco lo haría ...

Un certificado debe ser firmado por una autoridad de certificación (CA) confiable externa. Así que me topé con Let's Encrypt, que hace todo el trabajo por usted y es aún más fácil de configurar, y lo mejor es: es absolutamente gratis.

Instalación

1) Elimine sus viejos archivos de certificado SSL que ha creado utilizando OpenSSL

2) Abrir backports para obtener el cliente certbot en Debian. ¡Debe saber que esto abrirá un hueco para el software inacabado! Instale solo los paquetes cuando sepa lo que está haciendo.

echo 'deb http://ftp.debian.org/debian jessie-backports main' | sudo tee /etc/apt/sources.list.d/backports.list

3) Actualice su sistema Linux

sudo apt-get update

4) Instalar certbot

sudo apt-get install python-certbot-apache -t jessie-backports

5) Configurar apache ServerName y ServerAlias

sudo nano /etc/apache2/sites-available/000-default.conf

6) Editar el archivo de configuración de apache

<VirtualHost *:80>
    . . .
    ServerName example.com
    ServerAlias www.example.com
    . . .
</VirtualHost>

7) Verifique la sintaxis correcta

sudo apache2ctl configtest

8) Si el archivo de configuración se ve bien, reinicie el servidor apache

sudo systemctl restart apache2

9) Configure un certificado usando certbot y siga las instrucciones en pantalla.

sudo certbot --apache

Renovación

Todos los certificados de Let's Encrypt son válidos durante 3 meses. Para renovar el puede ejecutar manualmente

sudo certbot renew

O automatizar este servicio como un trabajo cron

sudo crontab -e

e ingrese la siguiente fila para invocar una renovación todos los lunes a las 2:30 a.m.

. . .
30 2 * * 1 /usr/bin/certbot renew >> /var/log/le-renew.log

Puede seguir un tutorial más detallado aquí: https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-debian-8

Si no ve otros errores SSL, y si ha intentado configurar 'LogLevel debug' en el archivo httpd.conf, este mensaje de error también puede sugerir que falta 'Listen 443' en el archivo httpd.conf.

Esos no son errores, son advertencias. Es bastante posible ejecutar mod_ssl con un certificado que no coincida con los nombres de servidor definidos siempre que tenga un host ssl predeterminado definido y el nombre común en el certificado coincida con el nombre de host utilizado por los clientes para conectarse.

Esto último no parece ser cierto en su caso. Como dice Jacob, debe especificar el nombre de host correcto como el nombre común (o un alias) cuando crea una CSR .

Para ver qué nombre (s) están actualmente en el certificado:

openssl s_client -showcerts -connect ${HOSTNAME}:443

Si hay varios certificados instalados en la máquina y se sirven en la misma dirección IP, entonces:

openssl s_client -showcerts -connect ${HOSTIP}:443 -servername ${HOSTNAME}

(donde los valores $ {...} son marcadores de posición que debe reemplazar con los valores relevantes).

Me encontré con este problema recientemente, cuando mi certificado autofirmado expiró. Busqué en Google y acabo de copiar el comando para crear un nuevo certificado desde un sitio web.

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/apache2/ssl/apache.crt

En mi archivo de configuración de apache: /etc/apache2/sites-available/default-ssl.conf. El archivo de certificado y el archivo de clave se refieren al siguiente nombre de archivo.

    SSLCertificateFile  /etc/apache2/ssl/apache.crt
    SSLCertificateKeyFile /etc/apache2/ssl/apache.key

Por lo tanto, el error visto aquí en mi caso fue una solución más fácil, simplemente al proporcionar la ubicación correcta del archivo de clave de certificado al crear el certificado SSL.

Entonces, aquí está el comando que debería haber usado y escrito correctamente.

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt

En mi caso, he resuelto esto reemplazado en mi archivo de configuración ssl de apache para cada dominio en cuestión:

ServerName mydomain.com
ServerAlias www.mydomain.com

por:

ServerName www.mydomain.com
ServerAlias mydomain.com

Porque mi certificado es para "www.midominio.com" y no para "midominio.com"

archivo completo de apache:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerAdmin noreply@mydomain.com
        ServerName www.mydomain.com
        ServerAlias mydomain.com
    DocumentRoot /home/mydomain.com/public_html
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|ico|png)$ \ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ \no-gzip dont-vary
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

    <Directory />
        Options +FollowSymLinks
        AllowOverride All
    </Directory>
    <Directory /home/mydomain.com/public_html>
        Options -Indexes +FollowSymLinks +MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
    </Directory>

    ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
    <Directory "/usr/lib/cgi-bin">
        AllowOverride All
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        Allow from all
    </Directory>


ErrorLog ${APACHE_LOG_DIR}/error.log

LogLevel warn
SSLCertificateFile /etc/letsencrypt/live/www.mydomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.mydomain.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Tuvimos que agregar ServerName y ServerAlias ​​al archivo default-ssl, no solo el archivo conf para el dominio específico.
Esto eliminó el molesto error para nosotros.