Many Problems With Managed Certificates -> Tasks: Credentials Aren't Consistently Used In Tasks

Question
1

I have successfully configured and completed request and generation of certificate, but in Tasks where I want the certificate deployed to a file share, credentials that work for one task on a remote file share don’t work in a similar task. For example, in Deploy to Generic Server, we have a Windows Credential stored that deploys the .pem files to a file share, like \server\certs. The same credentials are used to deploy to a CCS, which is on the same server, but the share is ccs, so \server\ccs. Both of those steps succeed, but if we add an Export Certificate step, again using the same credentials, and it’s even in the exact same file share, \server\certs, but app throws an access denied error. Now, how can that be true? It’s the same credentials and the same file share for Deploy to Generic Server, yet to export the pfx file, we get access denied errors. That doesn’t make sense to us, and this is the critical step b/c once that .pfx is exported, scripts are run to deploy it via group policy, etc.

And we also cannot get the Azure Key Vault deployment step to work at all, even though we have it set up correctly (we are an Azure consulting business, so I hope we know how to set up something this simple). In the error message, it says {“error”:{“code”:“BadParameter”,“message”:“The specified PKCS#12 X.509 certificate content can not be read. Please check if certificate is in valid PKCS#12 format.”}}

Once again we are very confused b/c in a prior step, the .pfx is generated correctly and stored in the ccs store for all of our websites (and this is done correctly), so why is it not available to export to Azure? We have tested the azure configuration numerous times, and it works, so for whatever reason, the .pfx file isn’t exported to azure correctly, even though it exists.

We had high hopes for this tool, but it is very difficult to use, things aren’t named consistently, and finding settings is very hard. But the two main things we need, exporting of the .pfx file both to a file share, and to Azure, aren’t working correctly. Exporting to CCS, or local cert store, they work just fine.

Also, why does the tool ask for a server name if you are using Windows Network credentials? The server name is in the \servername.

2

Hi, thanks for your feedback. I can assure that these features do actually work and other users are managing to use them but when problems do occur they can be hard to figure out especially when remote machines and remote services are involved. There is always room for better documentation and better error messages.

Export Certificate to UNC
When using the Export Certificate task the file path you provide must be a full filename e.g. \Somewhere\certs\example.pfx, not a folder.. This should be indicated in the UI before you fill out the file name field. The Deploy to CCS task only uses a folder instead because it controls the exact file name for you (CCS has specific naming conventions).

You are correct that copies to a UNC share (or local machine) don’t use the Hostname field at all, it’s things like the SSH option that use that, however there is no harm in providing the value.

Deploy to Azure KeyVault
Regarding Azure Key vault, “BadParameter” means azure didn’t understand your certificate as provided, it’s not actually having trouble accessing the file. You need to set a PFX password (Certificate > Advanced > Signing & Security) then re-request your certificate to rebuild the PFX. Azure Key Vault won’t accept a PFX with no password, also which CA are you using? If using Let’s Encrypt you may find you need to set “Preferred Issuer” (same setting location) to ISRG Root X1 as the default Let’s Encrypt chain is to the expired DST Root CA X3 chain which windows ignores but keyvault may care about.

Other Options
If ever you find a built-in task to be too limited you do have the option of providing your own PowerShell scripts: Scripting | Certify The Web Docs

In addition I assume you are a licensed user in which case you have access to the support email helpdesk support at certifytheweb.com where we can investigate these problem individually in greater detail. There’s pretty much always a solution, sometimes there is indeed a bug we need to fix but that’s less common.

If you have feedback on which settings in particular were hard to find or which fields in particular were inconsistent I’m sure we can review them. Some things do require familiarity with the app as there are literally hundreds of features and thousands of option combinations, unfortunately they can’t all be displayed in one window.