Crypt::LE (le64.exe) export-pfx cert not working in IIS 8

[bradpcmac]

le64.exe is mostly working great for us. I’m working on a project where we’re using IIS 8 on Server 2012, and we’re using the Central Certificate Store (CCS). The snag I’ve run into is when le64.exe outputs the .pfx file, IIS 8 is displaying a red X in the CCS, and the cert does not work. My current workaround is to run a PowerShell script that gets the PFX imported into IIS correctly. That script I found is here. Also, manually reimporting the cert in IIS 8 accomplishes the same thing. The script is quicker.

@leader
Is it possible for le64.exe to output a correctly formatted PFX file? I can give you examples of the PFX file before and after running that PowerShell script so you can compare. Or if you need any other info, I will gladly provide that to you. Just let me know the best way to do that (upload them here?, etc…). The domain I used is purely for testing.

My domain is: test5.madbray.com

I ran this command: (using le64.exe)
le64.exe --key mb_account.key --csr test5.madbray.com.csr --csr-key test5.madbray.com_priv.key --crt test5.madbray.com.pem --domains test5.madbray.com --generate-missing -handle-as dns --api 2 --export-pfx xxxxxxxxxxx --live

It produced this output:

2018/11/28 14:36:58 [ ZeroSSL Crypt::LE client v0.32 started. ]
2018/11/28 14:36:58 Loading an account key from mb_account.key
2018/11/28 14:36:58 Generating a new CSR for domains test5.madbray.com
2018/11/28 14:36:58 New CSR will be based on a generated key
2018/11/28 14:37:00 Saving a new CSR into test5.madbray.com.csr
2018/11/28 14:37:00 Saving a new CSR key into test5.madbray.com_priv.key
2018/11/28 14:37:01 Registering the account key
2018/11/28 14:37:01 The key is already registered. ID: 34310605
2018/11/28 14:37:01 Current contact details: brad@madbray.com, bradm413@gmail.com
2018/11/28 14:37:01 Challenge for 'test5.madbray.com' requires the following DNS record to be created:
Host: _acme-challenge.test5.madbray.com, type: TXT, value: emIoadZ8UunK0r-_7fi-LsmbMBlRwmmNHfsUGKcZla8
Wait for DNS to update by checking it with the command: nslookup -q=TXT _acme-challenge.test5.madbray.com
When you see a text record returned, press <Enter>

2018/11/28 14:38:36 Processing the 'dns' verification for 'test5.madbray.com'
2018/11/28 14:38:36 Domain verification results for 'test5.madbray.com': success.
2018/11/28 14:38:36 You can now delete '_acme-challenge.test5.madbray.com' DNS record
2018/11/28 14:38:36 Requesting domain certificate.
2018/11/28 14:38:37 Requesting issuer's certificate.
2018/11/28 14:38:37 Saving the full certificate chain to test5.madbray.com.pem.
2018/11/28 14:38:37 Exporting certificate to test5.madbray.com.pfx.
2018/11/28 14:38:37 The job is done, enjoy your certificate! For feedback and bug reports contact us at [ https://ZeroSSL.com | https://Do-Know.com ]

My web server is (include version): IIS 8

The operating system my web server runs on is (include version): Server 2012

My hosting provider, if applicable, is: n/a

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No

[leader]

Thanks for providing this information. This is actually quite interesting, even though a bit unexpected, since the output files are in a proper PKCS #12 format. Also as you have mentioned, importing and conversion work fine, which would not be the case if they were actually broken. From what I can see, this could be specific to Microsoft CCS expecting certain flags to be set. Some sources actually point out that it could be a problem with the MS UI rather than an actual issue with the certs. Specifically if the following is true:

• When the certificate is displayed with a red cross in CCS, double-clicking on it produces the information about the certificate just fine and confirms that the private key corresponds to the certificate.

• When CCS identity is set to an Administrator user, all information is displayed as expected, with no red cross against it.

Could you check if the above is indeed the case? Also having those before/after sent (for example via private message here) might help. Thanks.

[rg305]

The problem is that CCS can’t automatically open the PFX file without the required password.
Show it shows a red X - until you provide the password:

Which implies that all PFX certs managed by CCS should have that same password.

[bradpcmac]

@rg305 thanks for the info. We actually do already have the correct password configured in CCS like that, and we are using the same password for all pfx files we’re putting in there.

[bradpcmac]

Thanks for the reply. I have investigated this for you:

• When the certificate is displayed with a red cross in CCS, double-clicking on it produces the information about the certificate just fine – YES
• …and confirms that the private key corresponds to the certificate – I’m not sure where/how I check this
• When CCS identity is set to an Administrator user, all information is displayed as expected, with no red cross against it. – The user we’ve specified in the CCS Settings is indeed a user with administrative permissions

Here are some screenshots that may help give you context on what I’m seeing:

Also, I will private message you those 2 pfx files for comparison. They are actually different sizes (larger after importing into IIS). Thanks!

[leader]

Regarding the “private key corresponds to the certificate” - that should be stated on the General tab of the window opened by double-clicking on the certificate (last line on it, under “Valid from”). As for the user with the administrative permissions - is that user actually a member of Administrators group? In the tests done around that behaviour, the data has been correctly displayed for the administrators, but still displayed incorrectly (with the red cross) even if they users were given “Administrator role”.

Also as we can see on the screenshot posted by @rg305, the certificate exported by ZeroSSL is correctly displayed there, with the CCS identity set to administrator. I will look at pfx anyway of course, but so far this seems to be CCS-specific, rather than an actual issue with the format. Would you be able to check if the problem goes away if CCS is set with an administrator identity?

[bradpcmac]

@leader

“private key corresponds to the certificate”

Just checked, and it says it is valid.

@leader

is that user actually a member of Administrators group?

Yes, it is a domain account that is a member of the local Administrators group on the server. To my knowledge, this grants the highest level of permissions.

@leader

Would you be able to check if the problem goes away if CCS is set with an administrator identity?

How would I do that? I'm not sure what you mean by "administrator identity" in a Windows environment. I'm not familiar with that terminology.

When the cert has the red X for me, when I double-click on it, I see all the valid info. I ran another test with "test6" for the domain.

The odd thing to me was that the file sizes were different after importing the pfx manually into IIS. If this ends up being a CCS issue, I understand you are not here to support Microsoft's products. I appreciate you looking into this for me!

[leader]

So the user CCS runs as is in the administrators group. Does it have full control on the folder where the certificates are stored or it is read-only access (just checking, might not be the case)? By “identity” in this case I meant setting CCS with an actual “Administrator” user (similar to what you can see on @rg305’s screenshot) or one of the local admins. Unfortunately I do not have this specific setup available (with 2012 server + CCS in a domain) to check, but from what I recall from my previous experience, the user some service is running as (and the groups it belongs to, such as local or domain admins) might be relevant.

@rg305, seeing as you have seemingly similar setup, could you perhaps see what happens if the user CCS is set with is not an “administrator”? Thanks.

[rg305]

I would only need to see the passwords used.
Not even that, just compare the two passwords used.
Does your script even add a password to the PFX file?
Or does it basically just strip off the password?
If so, then if LE64 could accept a null password “” you may be able to get this working without the script.

[bradpcmac]

Oh ok, I think I see what you’re saying now. Yes, the user CCS runs as is an administrator (is a member of the local “Administrators” group). However, when I checked the Security permissions on the CCS directory, that user only has “Read & execute”, “List folder contents”, “Read” but not specifically “Full control”, “Modify”, or “Write” permissions. I will run this by the admin of that system and see if that was intentional for any reason and see where that leads. Thanks for the help. I will report back my findings. Hopefully this will take care of it. Still a little curious why the pfx file gets larger after the PowerShell script runs.

[bradpcmac]

I’m using the same password in the script that we’re using for CCS, so it’s not 2 passwords. When I run that PowerShell script, I re-import the cert using the same password I used in my le64.exe command with export-pfx.

Here’s the script I’m using. I leave the password statically set in the script so I don’t make a typo, but each time I run it I can specify the domain with user input in the script:

$dom = read-host "Enter domain name of the cert you want to import"
$pfxpath = "c:\certs\$dom.pfx"
$pfxpass = "xxxxxxxxxxx"

$mypwd = ConvertTo-SecureString -String $pfxpass -Force -AsPlainText
$pfx = new-object System.Security.Cryptography.X509Certificates.X509Certificate2
$pfx.Import($pfxpath, $pfxpass, "Exportable,PersistKeySet,MachineKeySet")
Export-PfxCertificate -Cert $pfx -FilePath $pfxpath -Password $mypwd

Hopefully that helps you get a better understanding of what I’m doing on this end. Thanks for all your help!

[rg305]

I think this:
Export-PfxCertificate -Cert $pfx -FilePath $pfxpath -Password $mypwd
does not equal:
Export-PfxCertificate -Cert $pfx -FilePath $pfxpath -Password $pfxpass

Because
$mypwd = ConvertTo-SecureString -String $pfxpass -Force -AsPlainText
changes $pfxpass to a secure string version of $mypwd.

One is like a sha256 hash of the other.
“Equal” but yet no longer exactly equal.
Which would also explain why one is larger than the other.

[bradpcmac]

Yeah, you’re probably right. I found this script on the link I specified above and adapted it to my purposes, but I didn’t change that part of the functionality. I’m not an expert in that area, so I left it as-is. Are you saying I shouldn’t do it this way, or just that it probably accounts for the file size discrepancy? --Thanks!

[rg305]

It creates an encrypted version of the original password.
It’s up to you how you want to continue.
But since CCS only allows for only one password…
If you use the encrypted version with the LE64 PFX export, it should just work.
For that, you will have to export the value of $mypwd in order to use it outside of powershell.
Which, of course, may reduce the overall security of that password; since it will need to be visibly stored in at least one additional place (LE batch file).
So you will have to ensure that script and output directories are properly locked down.

[bradpcmac]

Thanks, that makes sense why the file size is larger then.

If IIS handles the CCS password differently, would that mean that le64.exe could/should create the pfx file it outputs using a method that is compatible with Microsoft’s implementation here (using an encrypted form of the password I type into the le64 command)? or does IIS without CCS handle these correctly and this is only happening because we’re using CCS. I believe we can go to IIS -> Server Certificates -> Import… -> then export it and copy the resulting pfx file to the CCS and it works fine.

Is this issue (the red X in CCS) only happening because CCS is trying to read the pfx file using an encrypted version of the CCS password and thus expecting the certificate to have that same encrypted password on it?

Also, @leader I checked on the file permissions of the CCS directory, and the way we have it seems to be in line with how it’s supposed to be setup to keep that directory secure. Read access should be fine.

[rg305]

@bradpcmac

would that mean that le64.exe could/should create the pfx file it outputs using a method that is compatible with Microsoft’s implementation here (using an encrypted form of the password I type into the le64 command)?

I would think yes.

@bradpcmac

I believe we can go to IIS -> Server Certificates -> Import… -> then export it and copy the resulting pfx file to the CCS and it works fine.

Without the proper password, that should also show a red X - please try it (once).

@bradpcmac

Is this issue (the red X in CCS) only happening because CCS is trying to read the pfx file using an encrypted version of the CCS password and thus expecting the certificate to have that same encrypted password on it?

Basically, yes, CCS is only using one password for all files in the controlled folder.
Which seems to be the encrypted version powershell creates.