DevOps, Manage IIS Website task, netsh add sslcert, fails with error 1312 [closed]
Asked Answered
P

1

7

Trying to shift focus a bit based on initial feedback on the question.

In a DevOps release pipeline, using Manage IIS Website task, trying to add an https binding using a wildcard certificate. The certificate is in the local computer's certificate store (checked with mmc -> add snap-in "Certificates", select "Computer account" and "Local computer"), in the folder "Web Hosting\Certificates". I think this is where they end up when added from within IIS.

But when running the pipeline, it fails, with this entry in the log:

SSL Certificate add failed, Error: 1312
A specified logon session does not exist. It may already have been terminated.

The actual command line issued by the task is (anonymized by me):

"netsh" http add sslcert hostnameport=www.mydomain.se:443 certhash=*** appid={xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} certstorename=MY

As indicated in a comment, the certstorename param should apparently be assigned a different value. Fine.

But the task properties page offers no setting for this parameter, so how do I change it? And what should I shange it to?

If it can't be changed in the task, where should I move the cert to enable the task to find it with the value certstorename=MY? I have tried to find and understand docs about this, but failed, probably due to lacking basic knowledge about certificate stores in general and the associated terminology.

Putdown answered 15/5, 2020 at 12:47 Comment(3)
MY is a different store, so definitely you have to change it.Invitatory
@LexLi OK, so how do I change it? And what should I change it to? That was part of my question. I have looked.Putdown
OK, so I found a bug report about this: developercommunity.visualstudio.com/content/problem/239273/…Putdown
P
17

OK, so after a few more hours of digging I found the answers, as follows:

  1. In certmgr, the folders are really not folders but certificate stores. Not confusing at all.

  2. The subfolders "Certificates", "Certificate Revocation List" etc. are not really subfolders, but a way of sorting entries into their categories. Not confusing at all, either.

  3. The certificate store shown as "Personal" is denoted "MY" in script contexts. Not really confusing, but where is this really documented?

  4. Similarly, the certificate store shown as "Web Hosting" is probably denoted "WebHosting" without space in script contexts.

  5. IIS looks for certificates in both "WebHosting" and "MY", but as far as I understand "WebHosting" is preferred.

  6. The "Manage IIS Website" task for Azure DevOps release pipelines is hardcoded to only look in "MY". This has been reported as a problem here, but it was closed with a ref to the GitHub repo for all(?) Microsoft-authored tasks. I failed to find a corresponding issue there so I added one.

  7. The actual solution (workaround) is to copy or move the certificate from "WebHosting" to "MY", i.e. in certmgr drag it from "Web Hosting\Certificates" to "Personal", in which case a "subfolder" called "Certificates" magically appears. Note that the cert is not visible when "Web Hosting" is selected, you have to select the "subfolder" called "Certificates", but you should drag to "Personal" without adding a "Certificates" subfolder there first. Really very consistent, isn't it?

A good place to read about certs in Windows seems to be here, which would actually have been more helpful in a comment than a downvote and vote to close the question.

Putdown answered 15/5, 2020 at 14:57 Comment(2)
It's actually also very confusing that there are two "areas" or whetever for certificate stores: Local Computer and Current User, but each one contains the cert store "Personal" or "MY" as well as e.g. "WebHosting". So when a noob like me is faced with the "MY" store, it's clear as mud if it refers to the "Current User"... err... "area"(?), which would actually make more sense, considering the word "store", as opposed to "folder", which is how it's displayed in certmgr. The whole thing appears to be designed to be confusing on purpose.Putdown
"where is this really documented"? Microsoft expects such to be common knowledge (as it was there since very early Windows NT days), so not easy for new comers to know that. The post you linked "rediscovered" the facts and definitely can be helpful. "WebHosting" is preferred? Probably not. You probably got down voted as this question is not related to programming that much, but server management (so Server Fault might be a better site).Invitatory

© 2022 - 2024 — McMap. All rights reserved.