关于字符串：从Windows上的bash脚本运行Openssl – 主题不以’/’开头

Running Openssl from a bash script on windows - Subject does not start with '/'

在我的剧本中我有：

1
2
3
4
5
6
7
8

openssl req \
-x509 \
-new \
-nodes \
-key certs/ca/my-root-ca.key.pem \
-days 3652 \
-out certs/ca/my-root-ca.crt.pem \
-subj"/C=GB/ST=someplace/L=Provo/O=Achme/CN=${FQDN}"

在Git Bash 3.1中在Windows上运行它给出：

1	Subject does not start with '/'.

尝试逃避subj如下：
-subj"/ C = UK / ST = someplace / L = Provo / O = Achme / CN = $ {FQDN}"

仍然无法正常工作。有任何想法吗？

相关讨论

此问题特定于MinGW / MSYS，它通常用作Git for Windows软件包的一部分。

解决方案是使用前导//(双正斜杠)传递-subj参数，然后使用\(反斜杠)分隔键/值对。像这样：

1	"//O=Org\CN=Name"

然后将以预期的形式神奇地传递给openssl：

1	"/O=Org/CN=Name"

因此，要回答具体问题，您应该将脚本中的-subj行更改为以下内容。

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

这应该就是你所需要的。

这个魔法是什么？

对于那些对这里正在发生的事情感到好奇的人，我可以解释这个谜。原因是MSYS合理地假设包含斜杠的参数实际上是路径。当这些参数传递给一个尚未专门为MSYS编译的可执行文件(在本例中为openssl)时，它会将POSIX路径转换为Win32路径。这种转换的规则非常复杂，因为MSYS尽力涵盖互操作性的大多数常见场景。这也解释了为什么在Windows命令提示符(cmd.exe)中使用openssl工作正常，因为没有进行神奇的转换。

您可以像这样测试转换。

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

我们不能使用MSYS附带的echo可执行文件，因为它是为MSYS编译的，而是我们将使用cmd中内置的echo。请注意，由于cmd开关以/开头(常见于windows命令)，我们需要使用双斜杠处理它。正如我们在输出中看到的那样，参数被扩展为一个Windows路径，并且很明显为什么openssl确实声称Subject does not start with '/'.。

让我们看看更多转换。

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

双斜线使MSYS认为参数是一个Windows样式开关，导致仅剥离/(无路径转换)。你会认为通过这个我们可以使用斜杠来添加更多的键/值对。我们试试吧。

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

突然间，开始时的双斜线没有被剥离。这是因为现在，在初始双斜杠后面有一个斜杠，MSYS认为我们正在引用一个UNC路径(例如//服务器/路径)。如果这被传递给openssl，它将跳过第一个键/值Subject Attribute /O has no known NID, skipped。

以下是MinGW维基解释此行为的相关规则：

An argument starting with 2 or more / is considered an escaped Windows style switch and will be passed with the leading / removed and all \ changed to /.

Except that if there is a / following the leading block of /, the argument is considered to be a UNC path and the leading / is not removed.

在这个规则中，我们可以看到我们可以用来创建我们想要的参数的方法。由于以//开头的参数后面的所有\都将转换为plain /。让我们尝试一下。

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

我们可以看到它确实有效。

希望这可以揭开魔法的神秘面纱。

相关讨论

我个人发现这是特定于使用的OpenSSL二进制文件。在我使用msys2 / mingw64的系统上，我注意到存在两个不同的OpenSSL二进制文件，例如：

1
2
3
4

$ whereis openssl; echo; which openssl
openssl: /usr/bin/openssl.exe /usr/lib/openssl /mingw64/bin/openssl.exe /usr/share/man/man1/openssl.1ssl.gz

/mingw64/bin/openssl

我认为使用/mingw64/bin/openssl需要使用以//开头的主题，但是我不确定这是否特定于包/版本或OpenSSL的版本，所以可以肯定，版本每个二进制文件如下：

1
2
3

$ while read -r _openSslBin; do printf"${_openSslBin}:"; ${_openSslBin} version; done < <(whereis openssl | egrep -o '[^ ]+?\.exe ')
/usr/bin/openssl.exe: OpenSSL 1.0.2p 14 Aug 2018
/mingw64/bin/openssl.exe: OpenSSL 1.1.1 11 Sep 2018

我发现以下bash代码示例在使用msys / mingw在我的机器上工作时，根据OpenSSL版本选择正确的二进制文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# determine openssl binary to use based on OS
# -------------------------------------------
_os="$(uname -s | awk 'BEGIN{FS="_"} {print $1}' | egrep -o '[A-Za-z]+')"
if ["${_os,,}" ="mingw" ] || ["${_os,,}" =="msys" ]; then
while read -r _currentOpenSslBin; do
if [["$(${_currentOpenSslBin} version | awk '{print $2}')" =~ ^(1\.0\.[0-9].*|0\.\9\.8.*)$ ]]; then
_openSslBin="${_currentOpenSslBin}"
fi
done < <(whereis openssl | egrep -o '\/[^ ]+?\.exe ' | egrep -v 'mingw')
if [ -n"${_openSslBin}" ]; then
printf"OpenSSL Binary: ${_openSslBin} (v. $(${_openSslBin} version | awk '{print $2}'))
"
else
printf"Unable to find compatible version of OpenSSL for use with '${_os}' OS, now exiting...
"
exit 1
fi
else
_openSslBin="openssl"
fi

# display selected openssl binary and it's version
# ------------------------------------------------
printf"${_openSslBin}:"; ${_openSslBin} version

除了修复传递主题字符串的问题之外，我还发现这可以解决DN大小的问题(我传递了一个自定义openssl.cnf，其策略没有为任何字段设置max_size，但仍然存在问题当使用/mingw64/bin/openssl.exe时。