Erreur sur la conf HTTPD/mod_ssl Fermé

Question

Bonjour,

Je bloque sur l'erreur suivante suite au parametrage du fichier HTTPD.CONF en mode SSL pour une authetification simple du serveur.

[root@servname lib64]# /usr/local/apache/httpd-2.4.23/bin/apachectl configtest
httpd: Syntax error on line 140 of /usr/local/apache/httpd-2.4.23/conf/httpd.conf: Cannot load modules/mod_ssl.so into server: libssl.so.1.1: cannot open shared object file: No such file or directory

Je suis sur:
     => openssl (v1.1.0)
     => Apache (v2.4.23)
     => OS : Centos7

Je ne suis pas expert en linux, mais j'ai fais quelques checks pour verifier les versions installé et elle sont correcte. Mais j'ai des doutes sur les liens symboliques suivant qui pointe pas sur la bonne version.

Les fichiers concernés sont installé:

      /usr/local/apache/httpd-2.4.23/modules/mod_ssl.so (without link)
      /usr/local/openssl/openssl-1.1.0/lib/libssl.so -> libssl.so.1.1
      /usr/local/openssl/openssl-1.1.0/lib/libcrypto.so -> libcrypto.so.1.1

Les links sur les les fichiers sont:

[root@servname lib64]# ll /usr/lib64/libssl*
     /usr/lib64/libssl3.so
     /usr/lib64/libssl.so.10 -> libssl.so.1.0.1e
     /usr/lib64/libssl.so.1.0.1e
     /usr/lib64/libssl.so.1.1.0 -> libssl.so.10

[root@servname lib64]# ll /usr/lib64/libcrypto*
    /usr/lib64/libcrypto.so.10 -> libcrypto.so.1.0.1e
    /usr/lib64/libcrypto.so.1.0.1e
    /usr/lib64/libcrypto.so.1.1.0 -> libcrypto.so.10


Je ne comprends pas pourquoi je vois toujours des liens vers 1.0.e ? Pourriez-vous s'il vous plait nous aider à débloquer la situation.

Bien Cordialement

mamiemando · Answer

Bonjour,

Le problème est que le module apache ssl est linké avec libssl.so.1.1, or si tu regardes le contenu de /usr/lib64 il n'existe pas. On peut certes espérer que construire un lien symbolique vers /usr/lib64/libssl.so.1.1 vers /usr/lib64/libssl.so.1.1.0 suffise à résoudre le problème mais ce n'est pas une très bonne approche, car à la prochaine mise à jour de ssl tu risques d'avoir à nouveau ces problèmes (voir dernier paragraphe).

Pour moi le vrai problème est plus profond : tu souhaites installer openssl et apache et tu es passé par une installation "locale" (i.e. sans passer par ton gestionnaire de paquets, mais typiquement par une archive). Au lieu de ça tu aurais dû installer apache et openssl via ton gestionnaire de paquet (yum je suppose).

Ce que je te conseille, c'est donc de supprimer ton installation "locale" et d'installer apache et openssl via ton gestionnaire de paquets. L'autre avantage, c'est qu'apache et ssl seront mis à jour avec le reste du système. Une installation locale requiert quand à elle que tu fasses toi-même la mise à jour, et sur des briques logicielles qu'apache ou openssl, ce n'est pas une très bonne idée : il vaut mieux être à jour pour limiter les risques de failles de sécurité. Pour toutes ces raisons, il est toujours mieux (quand c'est possible) de privilégier une installation par paquets.

Enfin, concernant les numéros de version de librairies, tu n'es pas sensé t'en préoccuper. C'est la gestion en arrière boutique de linux des librairies. En gros un programme est linké avec un nom "générique" (mettons libssl.so) ou "un peu moins générique" (mettons libssl.so.1), qui est un lien symbolique qui pointe vers la version courante de la librairie. L'idée est qu'ensuite, lors d'une mise à jour de la librairie, il suffit de corriger ces liens symboliques pour pointer sur la librairie nouvellement déployée. C'est ce que fait ton gestionnaire de paquets (souvent en invoquant la commande ldconfig). Ce mécanisme permet aussi de faire co-éxister sur le même système plusieurs versions de la librairie. Mais en théorie, tu n'es jamais sensé "bidouiller" les liens symboliques en question. De manière générale d'ailleurs, tu n'es jamais sensé "bidouiller" sous linux.

Bonne chance

mamiemando · Answer

Le configure d'openssl et apach nécessite des options spéciales qu'on ne peut pas passer en YUM ou je me trompe.

Effectivement, avec des paquets classiques, le logiciel est déjà compilé, donc tu ne peux pas passer d'option de compilation. Mais les flags classiques sont souvent activés, donc à moins d'un besoin exotique, le paquet fait généralement l'affaire (ça vaut le coup de tester avant de se compliquer la vie avec des sources).

Dans ton cas ceci dit, je comprends que tu sois naturellement parti sur des sources, il est possible qu'effectivement les options dont tu as besoin ne soit pas active.

Pourriez-vous s'il vous plait me dire, en utilisant la commande YUM, comment puis je applique ce type de configuration? 

Quand les paquets binaires ne font pas l'affaire, paquets sources peuvent parfois être une alternative intermédiaire (le dernier recours étant de passer par une archive avec des sources en les compilant) :
https://superuser.com/questions/751035/is-there-an-option-for-yum-to-compile-from-source-instead-of-installing-pre-comp

Si je reste sur la méthode manuelle, qu'elle est la mise à jour à faire sur apache et openssl après l'installation? 

En fait ce sera à toi de recompiler apache et ssl (en suivant les mises à jour publiées sur les sites respectifs) à défaut de te reposer sur le gestionnaire de paquets. Dit autrement, le gestionnaire de paquets connait les paquets déployés, peut être lancé pour récupérer la liste des nouveaux paquets, et donc déterminer un scénario pour migrer vers les paquets à jour.

Un ldconfig permet ensuite en théorie de corriger les liens symboliques, mais parfois il faut les créer manuellement comme tu l'as fait quand tu as une erreur de linkage. Bien sur, sous réserve que cela pointe vers une version raisonnablement proche de la librairie attendue par le programme, sinon certains symboles (fonctions offertes par la librairies) peuvent ne pas exister ou être incompatibles.

Le problème est réglé en rajoutant un autre lien (Merci bq mamiemando :)

De rien :)

AH00526: Syntax error on line 92 of /usr/local/apache/httpd-2.4.23/conf/extra/httpd-ssl.conf: 
SSLSessionCache: 'shmcb' session cache not supported (known names: ). Maybe you need to load the appropriate socache module (mod_socache_shmcb?). 

As tu une idée de quoi il parle? 

Dans ce genre de situation, ton réflexe doit être de copier coller le message d'erreur dans google si tu ne le comprends pas. Tu tomberas sûrement sur des forums qui abordent déjà le problème et en explique la cause. Bien entendu le cas échéant, demander des précisions est la suite logique ;-)

Dans ton cas c'est visiblement un module apache (socache_shmcb) qui n'est pas installé et activé, comme le montre par exemple :
https://askubuntu.com/questions/365096/how-can-i-get-apache-ssl-to-work-in-13-10-after-upgrade
https://cuiborails.wordpress.com/2014/12/02/apache2-sslsessioncache-shmcb-session-cache-not-supported/

Attention toutefois, il s'agit d'une autre distribution, donc l'organisation des fichiers de configuration peut différer. Mais en gros sous debian et les distributions qui en dérivent, des "bouts" de fichiers de configuration sont exposés dans les répertoires /etc/{mod,sites,conf}-available, et effectivement considérés si le lien symbolique correspondant /etc{mod,sites,conf}-enabled/ pointe dessus. On en déduit que tu dois dans ton cas ajouter les bonnes directives apache pour activer le module.

Chose à savoir, pour que le changement de configuration d'un démon (ici apache2) soit pris en compte, il faut relancer le service (typiquement /etc/init.d/apache2 restart ou service apache2 restart ou systemctl apache2 restart). Parfois un "reload" suffit.

Bonne chance

Erreur sur la conf HTTPD/mod_ssl

2 réponses

Discussions similaires