L'exécution D'Openssl à partir d'un script bash sur Windows-Subject ne commence pas par'/'

Ce problème est spécifique à MinGW / MSYS qui est couramment utilisé dans le cadre du paquet Git for Windows.

La solution consiste à passer l'argument -subj avec // en tête (doubles barres obliques), puis à utiliser \ (barres obliques inverses) pour séparer les paires clé/valeur. Comme ceci:

"//O=Org\CN=Name"

Cela sera ensuite transmis par magie à openssl sous la forme attendue:

"/O=Org/CN=Name"

Donc, pour répondre à la question spécifique, vous devez changer la ligne -subj dans votre script à ce qui suit.

-subj "//C=GB\ST=someplace\L=Provo\O=Achme\CN=${FQDN}"

CE devrait être tout ce dont vous avez besoin.

Qu'est-ce de la magie?

Pour ceux qui sont curieux de savoir exactement ce qui se passe ici, je peux expliquer ce mystère. La raison en est que MSYS suppose raisonnablement que les arguments contenant des barres obliques sont en fait des chemins. Et lorsque ces arguments sont passés à un exécutable qui n'a pas été compilé spécifiquement pour MSYS (comme openssl dans ce cas), il convertit les chemins POSIX en chemins Win32 . Le les règles pour cette conversion sont assez complexes car MSYS essaie de son mieux pour couvrir les scénarios les plus courants pour l'interopérabilité. Cela explique également pourquoi l'utilisation de openssl à partir d'une invite de commande windows (cmd.exe) fonctionne correctement, car aucune conversion magique n'est effectuée.

Vous pouvez tester la conversion comme ceci.

$ cmd //c echo "/CN=Name"
"C:/Program Files (x86)/Git/CN=Name"

Nous ne pouvons pas utiliser l'exécutable echo fourni avec MSYS puisqu'il a été compilé pour MSYS, nous utiliserons plutôt le echo intégré dans cmd. Notez que depuis cmd Les commutateurs commencent avec / (commun pour les commandes windows), nous devons gérer cela avec des barres obliques doubles. Comme nous pouvons le voir dans la sortie, l'argument a été étendu à un chemin windows et il devient clair pourquoi openssl prétend en effet que Subject does not start with '/'..

Voyons d'autres conversions.

$ cmd //c echo "//CN=Name"
/CN=Name

Les doubles barres obliques font croire à MSYS que L'argument est un commutateur de style windows qui entraîne le retrait d'un / uniquement (pas de conversion de chemin). On pourrait penser qu'avec cela nous pourrions simplement utiliser des barres obliques pour ajouter plus des paires clé/valeur. Nous allons essayer que.

$ cmd //c echo "//O=Org/CN=Name"
//O=Org/CN=Name

Soudain, les doubles barres obliques au début ne sont pas dépouillées. C'est parce que maintenant, avec une barre oblique suivant les doubles barres obliques initiales, MSYS pense que nous référençons un chemin UNC (par exemple //server/path). Si cela était passé à openssl, il ignorerait la première clé/valeur en disant Subject Attribute /O has no known NID, skipped.

Voici la règle pertinente du wiki MinGW expliquant ce comportement:

• un argument commençant par 2 ou plus / est considéré comme un commutateur de style Windows échappé et sera passé avec le premier / supprimé et tout \ changé en /.
  • sauf que s'il y a un / suivant le bloc principal de /, l'argument est considéré comme un chemin UNC et le / principal n'est pas supprimé.

Dans cette règle, nous pouvons voir la méthode que nous pourrions utiliser pour créer l'argument que nous voulons. Puisque tout \ qui suit dans un argument commençant par // sera converti en simple /. Nous allons essayer ça.

$ cmd //c echo "//O=Org\CN=Name"
/O=Org/CN=Name

Et comme nous pouvons le voir, cela fonctionne.

J'espère que cela démystifie un peu la magie.