Gestion manuelle des certificats

Si vos certificats internes ou tiers ne sont pas stockés dans un centre de gestion de configuration distant tel que Vault, vous pouvez également définir les certificats localement dans un fichier JSON.

Certificats internes

Pour la certification interne entre les conteneurs Docker HCL Commerce, vous devez vous assurer que le nom commun (CN) de votre certificat et "SubjectAlternativeName" peuvent correspondre au nom d'hôte que les conteneurs Docker utiliseront. De plus, lorsque d'autres conteneurs source se connectent à un conteneur cible, le conteneur source doit utiliser le nom d'hôte du conteneur cible. Il existe une logique de vérification stricte pour vérifier si le nom d'hôte utilisé dans une requête est le même que SubjectAlternativeName dans le certificat du conteneur cible. Si les noms d'hôte ne correspondent pas, la connexion échoue.

Voici les SubjectAlternativeNames de la certification interne par défaut incluse dans les HCL Commerce conteneurs Docker :
SubjectAlternativeName [
  DNSName: *
  DNSName: app
  DNSName: web
  DNSName: search
  DNSName: store
  DNSName: tooling-web
  DNSName: store-web
  DNSName: query
  DNSName: data-query
  DNSName: ingest
  DNSName: nifi
  DNSName: registry
  DNSName: elasticsearch
  DNSName: zookeeper
  DNSName: localhost
  DNSName: search_master
  DNSName: search_repeater
  DNSName: search_slave
]
Si vous n'utilisez pas les noms d'hôte par défaut, vous devez reconfigurer les connexions entre les conteneurs. La liste suivante met en évidence certaines options de reconfiguration des connexions conteneurs.
  • Créez de nouveaux certificats et spécifiez le nom commun (CN) approprié et SubjectAlternativeName dans les certificats.
  • Si vous utilisez docker run pour déployer des conteneurs, utilisez la variable --add-host pour mapper l'adresse IP au nom d'hôte par défaut. Pour plus d'informations, voir Docker run documentation.
  • Si vous utilisez docker-compose pour déployer des conteneurs, tirez parti de la variable extra_hosts pour mapper l'adresse IP au nom d'hôte par défaut. Pour plus d'informations, voir Docker extra_hosts documentation. Par exemple, le nom d'hôte par défaut de la base de données est db. Si vous n'utilisez pas de conteneur Docker de base de données, vous devez utiliser la variable extra_hosts pour mapper l'adresse IP de la base de données au nom d'hôte db. Par exemple,
    extra_hosts:
        - "db:DatabaseServerIP"
    Voici deux exemples de fichiers YARL que vous pouvez utiliser comme référence pour l'utilisation de la variable extra_hosts.
  • Ajoutez un conteneur proxy pour mapper le nom d'hôte par défaut et le serveur cible.
Remarque : Si vous souhaitez remplacer les certificats internes par défaut, vous devez nommer le fichier JSON comme default.json. Dans le cas contraire, les certificats sont importés en utilisant le nom du fichier JSON comme alias dans la liste keystore.

Certificats externes

  • Pour une communication externe sécurisée entre un logiciel tiers HCL Commerce et un logiciel tiers, assurez-vous d'importer les informations de certification unidirectionnelle ou bidirectionnelle appropriées. Cela inclut l'exportation de vos clés publiques de certificat et leur importation dans votre magasin de clés de confiance d'application tierce.
  • Assurez-vous que votre code de personnalisation, que vous créez pour vous connecter à un logiciel tiers, utilisez le nom de certification correct.

Définition des informations de certificat dans un fichier JSON

Remarque : Lorsque vous copiez les certificats dans le fichier JSON, vous devez remplacer le retour à la ligne par \n pour vous assurer que la chaîne de certificat entière se trouve sur une seule ligne.
  • Pour la validation de certificat SSL unidirectionnel, lorsqu'une application a besoin d'un certificat pour communiquer avec une autre application activée par SSL, vous n'avez qu'à définir la issuing_ca dans le fichier JSON. Par exemple,
    {
     "issuing_ca": "-----BEGIN CERTIFICATE-----\nMIIFJjCCAw6gAwIBAgIUDUnfHPvwqpztM2lJh40lVUmTjV8wDQYJKoZIhvcNAQEL\nBQAwKzEpMCcGA1UEAwwgc2VsZnNlcnZlX3Byb2R1Y3Rpb25fcGtpIFJvb3QgQ0Ew\nHhcNMTcwODI1MDUwNTEzWhcNMjcwODIzMDUwNTQzWjArMSkwJwYDVQQDDCBzZWxm\nc2VydmVfcHJvZHVjdGlvbl9wa2kgUm9vdCBDQTCCAiIwDQYJKoZIhvcNAQEBBQAD\nggIPADCCAgoCggIBAM5LpBH9Qyg5VjTkdMj61gt72CVIrqE5s9iD+Bpb2hlLnWdb\n52FtcgCxIRca8kJhCYK53dNVmCP8d7LSzogxdIHyzEe5f405ukJVZIbYEYcA4BLK\n3UU322bYJkTTToABwV+XhlHjLhaze9GLo4snCklxAzafWvqR1C0faB2dPtq5WyQi\n/2uCvGHcpqe/ozNvZON6eYkjQpCwHftR0TwVVb435hvJb6FeeV95MgVq/C0pZFG4\nGLgJNj4GK4BtG2wsIDVMMcaoFrSKfKDqyE+4ekvzYP4nDzbYK5XsgH7/7XB9tL7w\nwMVj0J1mR3TbxVTBZyk509F0oXqBcNb6vvybJevhDlkXMQPgxyOmogm6GUQ3beMX\nsRpN5uotnbWaF0MQbgo8YrgQX3BGrLmKRfk9rIMoBKabptDMRw5Df1ouu5D9Jb3b\n3nlelkRXR5qb0R68CM0S78KqVB32NQsLixQ58YUKmcvlQcaIF9cwC28+LYm4sRq/\nV0tCl68K19PmgZT+Qr0Apakw+vlQ8ojvT+/wTVtg+gphuG7Ovv00xRXa/dpoC3Ff\nOktxUmu3bh4YU/IVCT3+YbwB7vyOfKGTwSmVK+s5gt4MDM65zX58xa85psJI8mqP\nCwKGDleglrAIrHxxg2wKrIibiIriSnjJsKqCzpcm9+6V4zewwQFqdfr1R92rAgMB\nAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQW\nBBQNl+8T/jYl1zV4Sct1EKqHBDcUUzANBgkqhkiG9w0BAQsFAAOCAgEAYo+vaKzi\nW2YTogGvuDvWnFzDtRa6zfB1UNqUTiacmr9ISqTDGJPOE7o7+5//31yS63/VuPAb\nsskfjtbywGUcjLEoa//vqDUA5VPQSr2MGpqZItt+QQ7eIQPQEt6IaqohmIxvgyDI\nvV35Ld06slZju9IZJdOx5GyRU49ZrhTciNeHBFJbPTzTWw7swjP1Kj13BJ9++YlU\ndHHnJecMgRPXbbFn8cThcIUwhaTEWFhlC7zc4YUpTm8nmHaCLmG8TM7tYLaymHqd\nypMBa3TrGr4+XIgwkWWb9h9+JnlBXc+aq2pJulErzN3raytzv+iTOwcI+YCufgee\nAf25Zzk9t75KIHjSdqu1U/QXiPSgJgr7o2yrtZbeLT+eMHuhCfbuWduipuRgTlUk\na8hvoiFDabCrlJABDYHNO8WMCIqX9qja0crqA1JbPXAEMiYwdtoU+p27CtNupGVE\nQENamacyYD5VhApTnxACwwakMep0jDYQUXUYTeLz6Aj3vVUJl54/3Uqbh6fxKamh\n8xDeb+HjhO5UKDkfAH0qe17qSGGVftMI3YMPCEqrvnnoVl8VHxpvdVjjJoHEEKoE\ne8mrX4Jp9O3xVcGFItMQQzvWc1A47ewqIy6x+bk+0W8fL6+rKd+8U7aRIvC7LFiw\nluvq3QIacuHULtox36A7HFmlYDQ1ozh+tLI=\n-----END CERTIFICATE-----"
    }
  • Pour la validation bidirectionnelle du certificat SSL, où SSL est activé sur les deux applications, vous devez définir plus d'informations. Par exemple,
    {
     "certificate": "-----BEGIN CERTIFICATE-----\nMIIETDCCAjSgAwIBAgIUTrvpjzgpyt6L9AWj2E0W4ps2woswDQYJKoZIhvcNAQEL\nBQAwKzEpMCcGA1UEAwwgc2VsZnNlcnZlX3Byb2R1Y3Rpb25fcGtpIFJvb3QgQ0Ew\nHhcNMTcwOTI2MDQ1NzM3WhcNMTcxMTIxMDQ1ODA3WjAPMQ0wCwYDVQQDEwR0ZXN0\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuWgQ5P9KjpgplOyejAE\nj5pDgSmQ6mZkbqY6gnIIKlw1I4Vulaigmeiir37NcAHtLA9HrpqafKoQqt3RPIFq\nMq2qb728JUNqdkmgp1QRnXdRVqrvGxT3o6XLMmxpkniwL+f3A/qFzuBgDJVltKLn\n1e0O3conPiiGtqaZ70+1lccKkKviLoin13T+27gFFws6dT74znCxT8c/ikXGMja1\nTDEddd+qkXlo4At104Fo7Uhx95JWorSljSTaCQkEeOjX+8SJHkARSrKeGEvkBESp\nXD23oUY9MlxGQnldioLAI5Eu8fRo3PKQUhuFnuoxTr0pO7R60AEe8E0sVU/cE3Ut\nswIDAQABo4GDMIGAMA4GA1UdDwEB/wQEAwIDqDAdBgNVHSUEFjAUBggrBgEFBQcD\nAQYIKwYBBQUHAwIwHQYDVR0OBBYEFLfcxphP+aSe61Mdi8IDP7bBvGXdMB8GA1Ud\nIwQYMBaAFA2X7xP+NiXXNXhJy3UQqocENxRTMA8GA1UdEQQIMAaCBHRlc3QwDQYJ\nKoZIhvcNAQELBQADggIBAH3oLFPSSgubbwhXycm+oTMnEZyUwKfwAjkc2mykDZ/p\nPPrHZKCfMuWNf8mp7mK0K8O2JjBKbUlUUJZgd/8/9d0vLqU7Hf97Xk/8d0Rxwqgd\n2OmdujQpj49NFoAC+jAcGFXASwvGAzWg4ylTi+zvpUbVpLk0hOpYnJFvxEcXj0ab\nul9Mq0hrjarmkPAoDhmWjUQG8EKiJEelIv5r4OuNIDl+N5B3BNU+g8nz4GWJKIbP\n6dEb98GJh0tFqOHoxewVmrCmMnsGfJYJDqLg+CwXHSNS8xYQnuFzcJXQ4j7Kge5P\nCeMB6fizgTiUXFexjbTv6RUk1DfOywtRu7Wus9joTpDILb/WlIUlGvRj2j395BvK\naq5nLcgSpmO46776uobh6MN6se1kmpJ20sjUZWEtJsKODSAv7LA9jsMWhh1SGEWf\nUuQ1hUKHZ2073hgc0InmYGGyTJAnI3mYIbL+ddprK1CpORAH2cruqn9I192sCWNw\npZIxuMCiRUrFWitKEkFwPfmDbVhPQ/ZvxMcdAHXJ+ZQ9RxcanmcBGnlvCjidOBZa\naLN2/Y99M26z+XcYG9rN0fx5Htf4UDENQ8kp8TITmyHdwvqVox/UXcPWzV3MD7+I\nn0UdA2lqnM2Rv+kg2MGm0u9Y/noZz4IS4YTlfxMbGF212ROcCC9/oQYy321NqBns\n-----END CERTIFICATE-----",
     "private_key": "-----BEGIN RSA PRIVATE KEY-----\nMIIEpQIBAAKCAQEAtuWgQ5P9KjpgplOyejAEj5pDgSmQ6mZkbqY6gnIIKlw1I4Vu\nlaigmeiir37NcAHtLA9HrpqafKoQqt3RPIFqMq2qb728JUNqdkmgp1QRnXdRVqrv\nGxT3o6XLMmxpkniwL+f3A/qFzuBgDJVltKLn1e0O3conPiiGtqaZ70+1lccKkKvi\nLoin13T+27gFFws6dT74znCxT8c/ikXGMja1TDEddd+qkXlo4At104Fo7Uhx95JW\norSljSTaCQkEeOjX+8SJHkARSrKeGEvkBESpXD23oUY9MlxGQnldioLAI5Eu8fRo\n3PKQUhuFnuoxTr0pO7R60AEe8E0sVU/cE3UtswIDAQABAoIBAB3kQ6An1K2NIvSs\nIzRTGru5k6TNfVDB8VIgOtnM90atEUY/7YXqLG1bFxOlnr/aoL+ds7J2tB8B0H2M\niUDhSdEEjyF6GgDhFspEWExgsgxRTuriPvfnIl4Nn7sa+tokfW8m8zkkPbBE/Y2w\n8RFnuoo9FzvqaSWAjBvX+LqjBWN4AGHxPcBcZs/H4U7RvdO0etX2Zbpjs62K/KO3\ni3e4MXgGZtj0Vx2LYD/AYSbqEoo1v8/U1AbGmsCTTNc2EwARhyb1zUgO7yc9yft6\nUoAC6pZjxOFsJtwz26jpNdqXz9t1xml3XnNusqHe+hgStQlIL2mgU8qj18q5pqpu\nkehM9LECgYEAxiU9WA7kQTp8hGKTRqrRbcGBsLTGxsYeILFQggtJBOZ5ngOH35Nd\nUIzQ1EjKODFEzGH9qPBBfE6BNdl3naHuYgIS3Uz8FCAwsOZAW6X8tC7VU/ZrwKUA\nF3Rc2iek+J1bdaz5o3hnR2eY/6kVuNHznxqIzK+JuZ7Dq/wEMlAL4gkCgYEA7Eyb\n4uyQFMXfPLiZPn7opNlgmi4i5lNLbPAjJq0dagdP8HbhLBqQThMcyAnu9rJmNm6t\n2Wu8kkKIpcZiGOVzFQvoTWOm6KGU/nIFFH1p6AAz/hvhATFA8HpLe9B7la9T6c5R\nabbtFbUNrHyoieMsIxkrjPo1zVIThLJeIVdoUNsCgYEAwuhKyV4MpSU06rxUhsTs\nsXwRaJLKnSiw5hPFT8ZuE0XrB8YNV52LwvphSRA46sF8HVeevxlmMTK/4wqBoSty\nZDIKAGoD5IAtpTU4xW4nf845xhe1spAb4PZzh5xLqMqQ9tYp0eVUImcDlyjp1x2e\n+TiOrFlXrqE/dOO39Q3MQpECgYEA5plMd4OMh/kiBcvQIOEQf+9zCoODo2od7U3b\nv96pGdPQ+0XIMJYrxUV5jO3EuhMXFH+mQMuW1tT/LWgQS2N/j0ZziTJ6rAMjt7vl\noT1SoQmxs4XZaqR6TzPJfibStBzJsx2Y7aWKcOijU3TDtOxxIj9p9MYowxoZ2iGH\nItp9/okCgYEAh6lbVbf77NArp1FsocQoeZ2ZL1hsOXpmRwpNmePPA6DfjqJyttpH\ngSh8Z0daqMvojStilhwIkEURy9ITuPYoKt2blWQY8RY//H1zFnwKg2AJR5PvlWcT\n0JBxt4cHMYy6jW2Q8/ZTVuttPd+UVIDehTFN6oyWF6FBgKxLO5bSjzc=\n-----END RSA PRIVATE KEY-----",
     "issuing_ca": "-----BEGIN CERTIFICATE-----\nMIIFJjCCAw6gAwIBAgIUDUnfHPvwqpztM2lJh40lVUmTjV8wDQYJKoZIhvcNAQEL\nBQAwKzEpMCcGA1UEAwwgc2VsZnNlcnZlX3Byb2R1Y3Rpb25fcGtpIFJvb3QgQ0Ew\nHhcNMTcwODI1MDUwNTEzWhcNMjcwODIzMDUwNTQzWjArMSkwJwYDVQQDDCBzZWxm\nc2VydmVfcHJvZHVjdGlvbl9wa2kgUm9vdCBDQTCCAiIwDQYJKoZIhvcNAQEBBQAD\nggIPADCCAgoCggIBAM5LpBH9Qyg5VjTkdMj61gt72CVIrqE5s9iD+Bpb2hlLnWdb\n52FtcgCxIRca8kJhCYK53dNVmCP8d7LSzogxdIHyzEe5f405ukJVZIbYEYcA4BLK\n3UU322bYJkTTToABwV+XhlHjLhaze9GLo4snCklxAzafWvqR1C0faB2dPtq5WyQi\n/2uCvGHcpqe/ozNvZON6eYkjQpCwHftR0TwVVb435hvJb6FeeV95MgVq/C0pZFG4\nGLgJNj4GK4BtG2wsIDVMMcaoFrSKfKDqyE+4ekvzYP4nDzbYK5XsgH7/7XB9tL7w\nwMVj0J1mR3TbxVTBZyk509F0oXqBcNb6vvybJevhDlkXMQPgxyOmogm6GUQ3beMX\nsRpN5uotnbWaF0MQbgo8YrgQX3BGrLmKRfk9rIMoBKabptDMRw5Df1ouu5D9Jb3b\n3nlelkRXR5qb0R68CM0S78KqVB32NQsLixQ58YUKmcvlQcaIF9cwC28+LYm4sRq/\nV0tCl68K19PmgZT+Qr0Apakw+vlQ8ojvT+/wTVtg+gphuG7Ovv00xRXa/dpoC3Ff\nOktxUmu3bh4YU/IVCT3+YbwB7vyOfKGTwSmVK+s5gt4MDM65zX58xa85psJI8mqP\nCwKGDleglrAIrHxxg2wKrIibiIriSnjJsKqCzpcm9+6V4zewwQFqdfr1R92rAgMB\nAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQW\nBBQNl+8T/jYl1zV4Sct1EKqHBDcUUzANBgkqhkiG9w0BAQsFAAOCAgEAYo+vaKzi\nW2YTogGvuDvWnFzDtRa6zfB1UNqUTiacmr9ISqTDGJPOE7o7+5//31yS63/VuPAb\nsskfjtbywGUcjLEoa//vqDUA5VPQSr2MGpqZItt+QQ7eIQPQEt6IaqohmIxvgyDI\nvV35Ld06slZju9IZJdOx5GyRU49ZrhTciNeHBFJbPTzTWw7swjP1Kj13BJ9++YlU\ndHHnJecMgRPXbbFn8cThcIUwhaTEWFhlC7zc4YUpTm8nmHaCLmG8TM7tYLaymHqd\nypMBa3TrGr4+XIgwkWWb9h9+JnlBXc+aq2pJulErzN3raytzv+iTOwcI+YCufgee\nAf25Zzk9t75KIHjSdqu1U/QXiPSgJgr7o2yrtZbeLT+eMHuhCfbuWduipuRgTlUk\na8hvoiFDabCrlJABDYHNO8WMCIqX9qja0crqA1JbPXAEMiYwdtoU+p27CtNupGVE\nQENamacyYD5VhApTnxACwwakMep0jDYQUXUYTeLz6Aj3vVUJl54/3Uqbh6fxKamh\n8xDeb+HjhO5UKDkfAH0qe17qSGGVftMI3YMPCEqrvnnoVl8VHxpvdVjjJoHEEKoE\ne8mrX4Jp9O3xVcGFItMQQzvWc1A47ewqIy6x+bk+0W8fL6+rKd+8U7aRIvC7LFiw\nluvq3QIacuHULtox36A7HFmlYDQ1ozh+tLI=\n-----END CERTIFICATE-----",
     "destination_host": "desthost"  //only required for the Transaction server. 
    }
    issuing_ca
    Cette clé contient l'intégralité de la chaîne de certificats de l'autorité de certification (CA).
    Par exemple, si le certificat est signé par un certificat intermédiaire et que le certificat intermédiaire est signé par un certificat de CA racine, le certificat intermédiaire et le certificat de CA racine doivent être tous deux inclus dans issuing_ca.
    L'ordre de ces certificats va du certificat intermédiaire au certificat racine.
    Par exemple, s'il existe deux certificats intermédiaires (I1 et I2), et que I1 est directement signé par le certificat racine ( R), l'ordre de ces signatures dans issuing_ca est : I2, I1, R.
    Chaque certificat doit être encapsulé dans "-----BEGIN CERTIFICATE-----" et " -----END CERTIFICATE-----"
    destination_host
    Ce paramètre n'est requis que dans le fichier JSON pour le Transaction server Docker container. Transaction server utilise du nom destination_host pour générer un SSL dynamique dans WebSphere Application Server qui s'exécute dans le conteneur.

Génération de certificats autosignés

Ce qui suit est un exemple généralisé de la façon de générer un certificat auto-signé. Vous pouvez également utiliser votre propre méthode de génération de certificats.

  1. Créez un fichier de configuration pour inclure les informations de certificat. Voici un modèle de fichier myconfiguration.conf.
    [req]
    default_bits = 2048
    prompt = no
    default_md = sha256
    req_extensions = req_ext
    distinguished_name = dn
    
    [ dn ]
    C=CA
    ST=Ontario
    L=Toronto
    O=HCL
    OU=Commerce
    emailAddress=emailAddress
    CN = current_domain_name
    
    [ req_ext ]
    basicConstraints = CA:TRUE
    keyUsage = nonRepudiation, digitalSignature, keyEncipherment
    subjectAltName = @alt_names
    
    [ alt_names ]
    DNS.0 = current_domain_name
    DNS.1 = ...
  2. Créer une clé privée. Utilisez la clé du fichier server.key.secure comme paire nom/valeur private_key du fichier JSON.
    openssl genrsa -out server.key.secure 2048
    
  3. Créez un certificat de requête avec des paramètres à partir du fichier de configuration.
    openssl req -new -key server.key.secure -out server.csr -config myconfiguration.conf
    
  4. Créez un certificat avec des paramètres à partir du fichier de configuration. Utilisez le certificat dans le fichier server.crt comme valeur de la paire nom/valeur du certificat dans le fichier JSON. Pour les certificats auto-signés, cette valeur est également la issuing_ca.
    openssl x509 -req -days 365 -in server.csr -signkey server.key.secure -out server.crt -extensions req_ext -extfile myconfiguration.conf
    Si vous utilisez une autorité de certification (CA), la issuing_ca est fournie par l'autorité de certification.
  5. Vérifiez le fichier et le certificat de requête pour vous assurer que SubjectAltName existe.
    openssl req -text -noout -in server.csr
    openssl x509 -in server.crt -text -noout

Chargement de fichiers JSON dans le répertoire /SETUP/certs/custom d'un conteneur Docker

Voici trois méthodes de copie des fichiers JSON sur votre image Docker.

  • Vous pouvez utiliser les deux commandes docker suivantes pour copier manuellement les fichiers JSON dans les conteneurs et créer le répertoire personnalisé s'il n'existe pas déjà.
    docker exec -u 0 container mkdir -p /SETUP/certs/custom/
    docker cp default.json container:/SETUP/certs/custom/
    
  • Vous pouvez utiliser l'instruction COPY dans un fichier Docker pour copier les fichiers JSON dans le répertoire /SETUP/certs/custom et créer une nouvelle image Docker. Par exemple, le fichier Docker suivant copie un fichier default.json dans le répertoire /SETUP/certs/custom.
    FROM Docker_registry/commerce/crs-app:source_image_tag
    COPY default.json /SETUP/certs/custom/
  • Vous pouvez personnaliser l'utilitaire WCB de façon à inclure les fichiers JSON dans le package de personnalisation d'entrée. Ensuite, lorsque vous générez une nouvelle image Docker avec votre package de personnalisation, le script /SETUP/bin/applyCustomization.sh place automatiquement vos fichiers JSON dans le répertoire /SETUP/certs/custom. Pour plus d'informations, voir Personnalisation de HCL Commerce Build tool.

L'importation des certificats locaux à partir du fichier JSON dans votre conteneur Docker en cours d'exécution est gérée par le script /SETUP/bin/updateLocaCerts.sh qui est inclus dans tous les conteneurs Docker fournis par HCL. Le script updateLocalCerts.sh effectue une recherche dans le répertoire /SETUP/certs/custom et charge l'ensemble des fichiers JSON.