Skip to main content

Enterprise Server 3.15 est actuellement disponible en tant que version finale (RC).

Résolution des erreurs TLS

Si vous rencontrez des problèmes TLS avec votre appliance, vous pouvez prendre des mesures pour les résoudre.

Suppression de la phrase secrète de votre fichier de clé

Si vous disposez d’une machine Linux sur laquelle OpenSSL est installé, vous pouvez supprimer votre phrase secrète.

  1. Renommez votre fichier de clé d’origine.

    mv yourdomain.key yourdomain.key.orig
    
  2. Générez une nouvelle clé sans phrase secrète.

    openssl rsa -in yourdomain.key.orig -out yourdomain.key
    

Vous êtes alors invité à entrer la phrase secrète de la clé au moment d’exécuter cette commande.

Pour plus d’informations sur OpenSSL, consultez la documentation d’OpenSSL.

Conversion de votre certificat ou clé TLS au format PEM

Si vous avez installé OpenSSL, vous pouvez convertir votre clé au format PEM à l’aide de la commande openssl. Par exemple, vous pouvez convertir une clé du format DER au format PEM.

openssl rsa -in yourdomain.der -inform DER -out yourdomain.key -outform PEM

Sinon, vous pouvez utiliser l’outil SSL Converter pour convertir votre certificat au format PEM. Pour plus d’informations, consultez la documentation de l’outil SSL Converter.

Installation sans réponse après le chargement d’une clé

Si votre instance GitHub Enterprise Server ne répond pas après avoir chargé une clé TLS, contactez le support GitHub Enterprise avec des détails précis, notamment une copie de votre certificat TLS. Vérifiez que votre clé privée n’est pas incluse.

Erreurs de validité de certificat

Certains clients comme les navigateurs web et Git en ligne de commande affichent un message d’erreur s’ils ne peuvent pas vérifier la validité d’un certificat TLS. Cela se produit souvent avec les certificats auto-signés ainsi que les certificats « racines chaînés » émis à partir d’un certificat racine intermédiaire qui n’est pas reconnu par le client.

Si vous utilisez un certificat signé par une autorité de certification, le fichier de certificat que vous chargez sur GitHub Enterprise Server doit inclure une chaîne de certificats avec le certificat racine de cette autorité de certification. Pour créer un tel fichier, concaténez l’intégralité de votre chaîne de certificats (ou « bundle de certificats ») à la fin de votre certificat, en veillant à ce que le certificat principal avec votre nom d’hôte arrive en premier. Sur la plupart des systèmes, vous pouvez faire cela avec une commande de ce type :

cat yourdomain.com.crt bundle-certificates.crt > yourdomain.combined.crt

Vous devriez pouvoir télécharger un bundle de certificats (par exemple, bundle-certificates.crt) à partir de votre autorité de certification ou fournisseur TLS.

Installation de certificats racines auto-signés ou d’une autorité de certification non approuvé

Si votre appliance GitHub Enterprise Server interagit avec d’autres machines sur votre réseau et qu’elles utilisent un certificat auto-signé ou non approuvé, vous devez importer le certificat racine de l’autorité de certification de signature dans le magasin de certificats à l’échelle du système afin d’accéder à ces systèmes via HTTPS. Si vous souhaitez utiliser un certificat signé par une autorité de certification interne, vous devez installer le certificat racine et tous les certificats intermédiaires.

  1. Obtenez le certificat racine de l’autorité de certification auprès de votre autorité de certification locale et vérifiez qu’elle est au format PEM.

  2. Copiez le fichier dans votre appliance GitHub Enterprise Server via SSH en tant qu’utilisateur « administrateur » sur le port 122.

    scp -P 122 rootCA.crt admin@HOSTNAME:/home/admin
    
  3. Connectez-vous à l’interpréteur de commandes d’administration de GitHub Enterprise Server via SSH en tant qu’utilisateur « administrateur » sur le port 122.

    ssh -p 122 admin@HOSTNAME
    
  4. Importez le certificat dans le magasin de certificats à l’échelle du système.

    ghe-ssl-ca-certificate-install -c rootCA.crt
    
  5. Pour appliquer la configuration, exécutez la commande suivante.

    Remarque : Durant une exécution de configuration, les services sur votre instance GitHub Enterprise Server peuvent redémarrer, ce qui peut entraîner un bref temps d’arrêt pour les utilisateurs.

    Shell
    ghe-config-apply
    
  6. Attendez la fin de l’exécution de la configuration.

Mise à jour d’un certificat TLS

Vous pouvez générer un nouveau certificat auto-signé ou mettre à jour un certificat TLS existant pour votre instance GitHub Enterprise Server avec l’utilitaire en ligne de commande ghe-ssl-certificate-setup. Pour plus d’informations, consultez « Utilitaires de ligne de commande ».

Résolution des problèmes liés aux communications de serveur après la mise à jour d’un certificat TLS

Si vous rencontrez des problèmes de communication ou d’autres problèmes sur votre serveur après la mise à jour d’un certificat, il peut y avoir des fichiers ou des liens symboliques manquants dans l’installation. Vérifiez la production de votre journal Web pour le message suivant.

 certificate verify failed (unable to get issuer certificate)

Si vous voyez ce message, il est probable qu’il y ait des certificats manquants ou mal configurés. Cela peut empêcher les services d’application de communiquer entre eux.

Pour corriger ce problème :

  1. Sauvegardez votre annuaire de certificats TLS actuel.

  2. Pour actualiser les certificats et le contenu qui peuvent être manquants dans l’annuaire /etc/ssl/certs, exécutez la commande suivante.

    Shell
    sudo update-ca-certificates --verbose --fresh
    

Si le problème persiste, contactez Support GitHub Enterprise.