Engadir un vhost que use https autofirmado a apache en Fedora 22
Nesta entrada explicarei cómo facer un vhost con certificado ssl autofirmado, esto ofrece unha conexión segura ao noso servidor, mais o certificado ao non ser autenticado por entidades certificadoras nos amosará alertas nos navegadores, que salvo que aceptémolo certificado seguirán aparecendo.
Instalación básica
Partimos da base de que xa temos un servidor httpd de Apache, configurado para servir páxinas correctamente configurado sen usar https.
Paquetes básicos
Vanos facer falta os paquetes mod_ssl e openssl:
# dnf install mod_ssl openssl
Xerando o certificado autofirmado
Unha vez instalados os paquetes procedemos a xerar a chave privada cun cifrado de máis de 2048 bits, canto máis pesado sexa máis forte e lento será, con 4096 bits en 2015 facemos un certificado ben forte:
# openssl genrsa -out <nome_host>.key <tamaño_en_bits>
Agora hai que facer a solicitude de firma de certificado o CSR:
# openssl req -new -key <nome_host>.key -out <nome_host>.csr
Enchémolos campos que nos piden, se poñemos contrasinal esta nos será requerida cada vez que se inicie o demo httpd.
Polo xeral non se soe usar unha contrasinal para protexelo, xa que requiriría de introducila cada vez que se reinicie o servizo.
Por último xeramos un certificado autofirmado de tipo x509, dándolle a validez en días que queiramos, unha vez pasada esa data os usuarios verán unha advertencia de que está caducado, mais seguirá funcionando (cando o usuario confirme que non lle importa ).
# openssl x509 -req -days <número_de_días> in <nome_host>.csr -singkey <nome_host>.key -out <nome_host>.crt
Unha vez creado o certificado, copiamos os arquivos os directorios correspondentes:
# cp -v <nome_host>.crt /etc/pki/tls/certs/
# cp -v <nome_host>.key /etc/pki/tls/private/
# cp -v <nome_host>.csr /etc/pki/tls/private/
Configurando httpd apache para usar os certificados autofirmados
En fedora gostan de darlle moitas voltas as cousas, polo que teremos que editar o arquivo /etc/httpd/conf.d/ssl.conf , en lugar de engadir as directivas directamente no arquivo de configuración do vhost, que tamén se podría.
Editamos /etc/httpd/conf.d/ssl.conf e nas liñas correspondentes engadimos os arquivos que acabamos de facer:
# ...
SSLCertificateFile /etc/pki/tls/certs/<nome_host>.crt
# ...
SSLCertificateKeyFile /etc/pki/tls/private/<nome_host>.key
# ...
SSLCertificateChainFile /etc/pki/tls/certs/<nome_host>.crt
# ...
Creando o vhost seguro
Agora facemos un vhost que usará https para as súas conexións, para elo editamos ou creamos o arquivo /etc/httpd/conf.d/.conf co seguinte contido:
# ... Aquí pode ir a configuración do vhost http en plano para o porto 80
#
<VirtualHost *:443>
ServerAdmin <email_de_contacto>
ServerName <nome_vhost>
ServerAlias www.<nome_vhost> <subdomino>.<nome_vhost>
DocumentRoot <ruta_da_raiz_do_sitio>
SSLCertificateFile /etc/pki/tls/certs/<nome_vhost>.crt
SSLCertificateKeyFile /etc/pki/tls/private/<nome_vhost>.key
# O directory é opcional.
<Directory <ruta_da_raiz_do_sitio> >
Require all granted
Options FollowSymLinks MultiViews
AllowOverride AuthConfig FileInfo Indexes Limit
Order allow,deny
allow from all
</Directory>
# A directiva Files tamén é opcional isto asegura que non se sirvan os .htaccess e outros ficheiros
# que comecen por .ht , tamén se poden agregar os .git e .svn, se os tiveras.
### File protection
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>
</VirtualHost>
Unha vez configurado httpd, podemos reinicialo ou recargar a sua configuración:
# systemctl reload httpd
Dando acceso externo ao vhost seguro
Pode suceder que non funcione dende fora do host o noso vhost por http ou https, isto se debe ao firewall configurado en fedora, que de serie ven resitrictivo con este tipo de conexións.
Polo que debemos permitir o acceso ao porto 443 no caso de https e o 80 no caso do http normal:
# firewall-cmd --add-service=https --permanent
# firewall-cmd --add-service=http --permanent
# firewall-cmd --reload
Posibles fallos
Pode ser que siga dicindo que non tes permisos de acceso mais xa un erro amosado por httpd (polo que tes, conexión co server).
Tes que revisar os permisos e as políticas de acceso aos directorios de SElinux, mais en todo caso NUNCA DESHABILITES SELINUX, andar sen SELinux e expoñer o sistema a ser manipulado por httpd en caso de que este sexa víctima de algún exploit por descubrir…
