OpenSSL OpenBSD OSX.8.5 server

Mangopomme

Nouveau membre
3 Février 2016
4
0
64
Bonjour,

Sur des macs (développement et exploitation) mon serveur web (une base 4D) utilise OpenBSD pour déterminer les barrages et la translation du port 80. Je travaille maintenant sur la publication en https, et l'adjonction d'une règle de translation pour le port 443 a été effectuée avec succès.

J'ai fait ensuite l'apprentissage d'OpenSSL et du nécessaire pour générer les docs KEY CSR et CRT autosigné.

Avant de publier sous ce mode, et de demander le certificat à une autorité, je peux donc me connecter avec un navigateur en https à l'une ou l'autre de ces machines. Les connections s'établissent en https (avec les avertissements d'usage par les navigateurs).

Les commandes OpenSSL permettant de consulter sous différents aspects les documents chiffrés KEY + CSR + CRT sont opérationnelles sur les deux machines, tout monte et les "modulus" correspondent.

Mais il y a une différence notable de comportement avec la commande s_client du terminal, qui établit très bien la connexion sur la machine de développement, mais pas sur sur la machine opérationnelle.

Je cherche sans succès pour l'instant ce qui peut causer un tel problème. La commande s_client semble ne pas établir pas la connection sur la ligne de commande "s_client -connect host:port -tls1" ni "s_client -connect host:port -msg", et après un time out renvoie l'erreur "connect:errno=60" sur chacune des ces opérations.


La machine de développement est un iMac OSX95, et celle de production est un MacMini server OSX85. Les versions OpenSSL comme 4D sont identiques. En consultant diverses documentations j'ai observé que la configuration /etc/pf.anchors/com.apple est sensiblement différente sur une configuration OSX server.

Pour résumer le standard c'est :
anchor "200.AirDrop/*"
anchor "250.ApplicationFirewall/*"

Le server c'est :
scrub-anchor "100.InternetSharing/*"
scrub-anchor "300.NetworkLinkConditioner/*"
nat-anchor "100.InternetSharing/*"
rdr-anchor "100.InternetSharing/*"
anchor "100.InternetSharing/*"
anchor "200.AirDrop/*"
anchor "250.ApplicationFirewall/*"
dummynet-anchor "300.NetworkLinkConditioner/*"
anchor "300.NetworkLinkConditioner/*"

Ce qui fait une grosse différence, même sans connaître le contenu de ces documents supplémentaires.

L'objet de ce post est donc de demander aux experts que ce sujet inspirerait, si c'est une bonne piste pour chercher la cause de ce problème.

Et je les remercie beaucoup d'avance pour toutes indications utiles.

Bon week end en tout cas.
 

bompi

El Moderador
Modérateur
Club MacG
12 Février 2004
41 895
3 141
Que vient faire OpenBSD : les Macs fonctionnent sous OpenBSD, ou alors tu l'as installé dans des machines virtuelles ?
 

Mangopomme

Nouveau membre
3 Février 2016
4
0
64
Bonjour Bompi, OpenBSD est en effet installé "en usine", et j'ai comme beaucoup de personnes effectué la petite manipulation shell qui permet de rerouter les ports d'arrivées vers ports internes (80,443).

La différence de configuration entre OSX8 server et OSX8 standard m'avait paru la possible cause d'un problème perceptible sous OpenSSL, décrit plus haut.

J'ai pu finalement faire fonctionner le test s_client de OpenSSL sur cette machine OSX8 server, en indiquant le port d'arrivée 443 et non le port interne (4433 ou autre).

Les tests s_client et les tests avec navigateur std montrent que les connections SSL sont parfaitement opérationnelles, mon objectif est donc atteint.

Reste donc une petite différence de comportement entre OSX standard et server, sachant que sur le premier, je peux entrer comme argument le port interne.

Il me reste à comprendre pourquoi cette différence. La configuration physique de la machine en OSX8 server est je crois augmentée d'une carte supplémentaire. J'ai vu un en1 sur server qui n'apparait pas sur standard.

Bonne journée à tous.