Try doing the following:
echo '/C=UK/'
This will output /C=UK/ literally. However, if I try using it in a program...
openssl req -subj '/C=UK/' (...)
Then I get the following:
req: the subject name is expected to be in the format /type0=value0/type1=value1/type2=... where characters may be escaped by \. This name is not in that format: 'C:/Programs/Repository/Git/C=UK/'
What causes the standard git bash/minGW environment to mangle any value starting with a forward slash when used as an input for a program (but not plain bash functions such as echo), even if using single quotes?
Attempting to work around it using a variable does not function.
SUBJ='/C=UK/'
openssl req -subj "$SUBJ" (...)
results in the same exact error.
The solution has to do with something called 'POSIX Path rewriting', which minGW has interpreted meaning to mangle paths used in arguments by prepending whatever its windows install path is. This messes up both windows tools and the command line tools inside git bash, because not every variable starting with a slash is a path.
(In this case, it's an openssl or LDAP string).
The exact solution is to set the following environment variable:
export MSYS_NO_PATHCONV=1
Using any other means than export will also fail. This is quite the buggy behaviour that caught me off guard, and search initially didn't lead me to the answer (until I randomly came upon using the word 'mangle').
Also see How to stop MinGW and MSYS from mangling path names given at the command line