SSL a cessé de fonctionner

1

Mon SSL a soudainement cessé de servir mon site. C'est peut-être parce que j'ai installé nginx sur mon serveur, puis que je l'ai désinstallé avec apt-get purge nginx *

Pendant environ 30 minutes, il servait des pages au lieu d’Apache. Après l'avoir purgé, Apache est revenu à la normale ... ou presque. Il ne sert toujours pas le contenu SSL, mais il servira les autres hôtes virtuels du serveur.

Je me suis également assuré que mes ports 80 et 443 sont ouverts.

J'ai 3 sites activés en ce moment. Lorsque je lance Apache, je ne reçois aucun message d'erreur. Voici le contenu de 000-default.conf, default-ssl.conf et elaan.conf

000-default.conf

<VirtualHost *:80>

ServerAdmin [email protected]
DocumentRoot /var/www/html/elaan/

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

default-ssl.conf

<IfModule mod_ssl.c>
<VirtualHost _default_:443>
    ServerAdmin [email protected]
    ServerName elaan.com.tw:443

    DocumentRoot /var/www/html/elaan

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    SSLEngine on

    SSLCertificateFile /etc/apache2/ssl/ssl.crt
    SSLCertificateKeyFile /etc/apache2/ssl/private.key
        SSLCertificateChainFile /etc/apache2/ssl/sub.class1.server.ca.pem


    <FilesMatch "\.(cgi|shtml|phtml|php)$">
            SSLOptions +StdEnvVars
    </FilesMatch>
    <Directory /usr/lib/cgi-bin>
            SSLOptions +StdEnvVars
    </Directory>

    BrowserMatch "MSIE [2-6]" \
            nokeepalive ssl-unclean-shutdown \
            downgrade-1.0 force-response-1.0
    # MSIE 7 and newer should be able to use keepalive
    BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

</VirtualHost>
</IfModule>

elaan.conf

<VirtualHost *:80>

ServerAdmin [email protected]
ServerName elaan.com.tw
ServerAlias www.elaan.com.tw
DocumentRoot /var/www/html/elaan

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

tous ces sites sont dans le dossier activé par le site lorsque j'exécute le service apache2 reload, et le fichier error.log ne contient aucun message d'erreur.

Quelqu'un peut-il offrir des idées sur la manière de vérifier plus avant pourquoi Apache ne sert pas à partir de https: //?

# netstat -tlnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1003/sshd       
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1335/sendmail: MTA:
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      1104/mysqld     
tcp        0      0 127.0.0.1:587           0.0.0.0:*               LISTEN      1335/sendmail: MTA:
tcp6       0      0 :::22                   :::*                    LISTEN      1003/sshd       
tcp6       0      0 :::443                  :::*                    LISTEN      1443/apache2    
tcp6       0      0 :::80                   :::*                    LISTEN      1443/apache2 

ports.conf

Listen 80

<IfModule ssl_module>
    Listen 443
</IfModule>

<IfModule mod_gnutls.c>
    Listen 443
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

ssl_engine.log

[Tue Jul 14 12:18:18.811639 2015] [ssl:debug] [pid 11551] ssl_engine_pphrase.c(181): AH02199: SSL not enabled on vhost 127.0.1.1:80, skipping SSL setup
[Tue Jul 14 12:18:18.811892 2015] [ssl:debug] [pid 11551] ssl_engine_pphrase.c(239): AH02202: Init: Read server certificate from '/etc/apache2/ssl/ssl.crt'
[Tue Jul 14 12:18:18.812048 2015] [ssl:info] [pid 11551] AH01887: Init: Initializing (virtual) servers for SSL
[Tue Jul 14 12:18:18.812589 2015] [ssl:info] [pid 11551] AH01876: mod_ssl/2.4.7 compiled against Server: Apache/2.4.7, Library: OpenSSL/1.0.1f
[Tue Jul 14 12:18:18.836129 2015] [ssl:debug] [pid 11552] ssl_engine_pphrase.c(181): AH02199: SSL not enabled on vhost 127.0.1.1:80, skipping SSL setup
[Tue Jul 14 12:18:18.840838 2015] [ssl:debug] [pid 11552] ssl_engine_pphrase.c(239): AH02202: Init: Read server certificate from '/etc/apache2/ssl/ssl.crt'
[Tue Jul 14 12:18:18.841171 2015] [socache_shmcb:debug] [pid 11552] mod_socache_shmcb.c(389): AH00821: shmcb_init allocated 512000 bytes of shared memory
[Tue Jul 14 12:18:18.841180 2015] [socache_shmcb:debug] [pid 11552] mod_socache_shmcb.c(405): AH00822: for 511912 bytes (512000 including header), recommending 32 subcaches, 88 indexes each
[Tue Jul 14 12:18:18.841185 2015] [socache_shmcb:debug] [pid 11552] mod_socache_shmcb.c(438): AH00824: shmcb_init_memory choices follow
[Tue Jul 14 12:18:18.841189 2015] [socache_shmcb:debug] [pid 11552] mod_socache_shmcb.c(440): AH00825: subcache_num = 32
[Tue Jul 14 12:18:18.841193 2015] [socache_shmcb:debug] [pid 11552] mod_socache_shmcb.c(442): AH00826: subcache_size = 15992
[Tue Jul 14 12:18:18.841196 2015] [socache_shmcb:debug] [pid 11552] mod_socache_shmcb.c(444): AH00827: subcache_data_offset = 2128
[Tue Jul 14 12:18:18.841210 2015] [socache_shmcb:debug] [pid 11552] mod_socache_shmcb.c(446): AH00828: subcache_data_size = 13864
[Tue Jul 14 12:18:18.841214 2015] [socache_shmcb:debug] [pid 11552] mod_socache_shmcb.c(448): AH00829: index_num = 88
[Tue Jul 14 12:18:18.841286 2015] [socache_shmcb:info] [pid 11552] AH00830: Shared memory socache initialised
[Tue Jul 14 12:18:18.841290 2015] [ssl:info] [pid 11552] AH01887: Init: Initializing (virtual) servers for SSL
[Tue Jul 14 12:18:18.841851 2015] [ssl:info] [pid 11552] AH01876: mod_ssl/2.4.7 compiled against Server: Apache/2.4.7, Library: OpenSSL/1.0.1f
[Tue Jul 14 12:18:18.844054 2015] [mpm_prefork:notice] [pid 11552] AH00163: Apache/2.4.7 (Ubuntu) PHP/5.5.9-1ubuntu4.9 OpenSSL/1.0.1f configured -- resuming normal operations
[Tue Jul 14 12:18:18.844069 2015] [mpm_prefork:info] [pid 11552] AH00164: Server built: Mar 10 2015 13:05:59
[Tue Jul 14 12:18:18.844085 2015] [core:notice] [pid 11552] AH00094: Command line: '/usr/sbin/apache2'
[Tue Jul 14 12:18:18.844090 2015] [mpm_prefork:debug] [pid 11552] prefork.c(995): AH00165: Accept mutex: fcntl (default: sysvsem)

Statut du pare-feu:

 To                         Action      From
 --                         ------      ----
[ 1] 22                         ALLOW IN    Anywhere
[ 2] 80                         ALLOW IN    Anywhere
[ 3] 443/tcp                    ALLOW IN    Anywhere
[ 4] 443/tcp                    ALLOW OUT   Anywhere (out)
[ 5] 587                        ALLOW OUT   Anywhere (out)
[ 6] 22 (v6)                    ALLOW IN    Anywhere (v6)
[ 7] 80 (v6)                    ALLOW IN    Anywhere (v6)
[ 8] 443/tcp (v6)               ALLOW IN    Anywhere (v6)
[ 9] 443/tcp (v6)               ALLOW OUT   Anywhere (v6) (out)
[10] 587 (v6)                   ALLOW OUT   Anywhere (v6) (out)
Jonnyjandles
la source
Vous dites que vous avez vérifié que les ports 80 et 443 sont ouverts, mais avez-vous vérifié que le PID apache écoute réellement le port 443 via Netstat ou quelque chose d'autre?
ssnobody
J'ai posté les résultats de netstat dans la question ci-dessus. Il me semble qu’elle écoute 443, mais je ne suis pas sûre, car l’adresse locale et l’adresse étrangère paraissent vides. En outre, il semble qu’il n’écoute que tcp6 sur ces ports.
jonnyjandles
Les connexions au délai d'attente du serveur entraînent-elles une erreur différente ou autre chose?
Personne
La barre d'informations en bas du navigateur indique la connexion. Puis, éventuellement, la connexion expire. Il n'y a pas de journaux dans le fichier access.log. Une connexion TCP6 est-elle également suffisante pour fonctionner avec TCP v4?
jonnyjandles
La connexion tcp6 devrait être suffisante pour accepter les connexions IPv4 et IPv6 si le mappage était activé. Voir httpd.apache.org/docs/2.2/bind.html . Si vous obtenez des délais d'attente, cela signifie que vous n'avez pas réussi à atteindre l'apache en écoute. Cela serait probablement dû à des problèmes de pare-feu ou de routage. Essayez de telnet d’hôte local au port 443 et voyez si la connexion s’affiche dans netstat; si cela fonctionne, essayez la même chose de distant.
Personne

Réponses:

1

Enfin, nous avons suivi le problème jusqu'au pare-feu. J'ai pu me connecter via la ligne de commande de l'hôte local, mais pas à partir de machines distantes. Pour une raison quelconque, la désactivation de la règle ALLOW 443 OUT a permis de résoudre le problème.

Jonnyjandles
la source