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
ort -tls1" ni "s_client -connect hostort -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.
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
ort -tls1" ni "s_client -connect hostort -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.
