API N0C, certificats SSL Let's Encrypt
Refusé
L'API /v3/hosting/domain/ssl pourrait renvoyer les données détaillées du certificat ('key' et 'cert') lorsqu'on est sur du Let's Encrypt. Comme c'est le cas pour les certificats personnalisés (/v3/hosting/domain/ssl/custom).
Le besoin : scripts NodeJs qui ont besoin des données de certificat pour ouverture de serveurs https. Contexte migration de CPanel vers N0C, l'API CPanel permettait d'obtenir ces informations.
La recherche manuelle des fichiers n'est pas une option assez fiable, en tous cas ne l'était pas sous CPanel - notamment dans les cas de renouvellement.
J'aime cette idée 
Keine Verbindung
Echtzeitbenachrichtigungen funktionieren möglicherweise nicht
Bonjour cher client,
Merci de nous avoir contactés et pour votre suggestion concernant l’API SSL.
Pour l’instant, nous avons marqué cette idée comme refusée afin de collecter davantage d’informations et de mieux comprendre le besoin.
En théorie, si une application Node.js est installée sur l’hébergement tel que recommandé via N0C et gérée par Passenger, elle ne devrait pas créer son propre serveur. En effet, c’est Passenger et Apache qui servent l’application, ce qui garantit que celle-ci est en SSL dès le départ.
De plus, par défaut, nous bloquons toute tentative de lancer des processus sur les ports 80, 443, 3000, ou tout autre port non spécifiquement ouvert dans nos configurations, en dehors de la gestion par nos processus.
Si cette explication ne répond pas pleinement à votre besoin, nous vous invitons à ouvrir un billet de service et à mentionner la référence Feature #767.
Merci pour votre collaboration et votre compréhension.
Bonjour cher client,
Merci de nous avoir contactés et pour votre suggestion concernant l’API SSL.
Pour l’instant, nous avons marqué cette idée comme refusée afin de collecter davantage d’informations et de mieux comprendre le besoin.
En théorie, si une application Node.js est installée sur l’hébergement tel que recommandé via N0C et gérée par Passenger, elle ne devrait pas créer son propre serveur. En effet, c’est Passenger et Apache qui servent l’application, ce qui garantit que celle-ci est en SSL dès le départ.
De plus, par défaut, nous bloquons toute tentative de lancer des processus sur les ports 80, 443, 3000, ou tout autre port non spécifiquement ouvert dans nos configurations, en dehors de la gestion par nos processus.
Si cette explication ne répond pas pleinement à votre besoin, nous vous invitons à ouvrir un billet de service et à mentionner la référence Feature #767.
Merci pour votre collaboration et votre compréhension.
Les commentaires de cette page ont été verrouillés !