Blank Friendly Name in Exchange 2016

Operating system : Windows Server 2012R2 Exchange version: 2016cu3 Win-acme version 2.1.12.943

Downloaded and ran Win-acme, created a certificate with 4 names, ran DNS authentication, generated the certificate selected Windows Certificate Store to store certificate.

Did not see the instructions to run an exchange import script before exiting win-acme

Ran mmc and using certificate import COULD NOT FIND the certificate in ANY windows store.

Ran Exchange ECP and certificate did not appear in the list of certificates.

Ran IIS configuration and certificate DID appear in lists of certificates. Selected it for default website.

Accessed default website and downloaded the DER file of certificate (lacking the private key)

Ran Exchange ECP and imported the certificate DER file. Certificate DID NOT show in Exchange.

Rebooted server. Accessed Exchange again. Now, certificate DOES appear in the list of Exchange-selectable certificates - but it lacks an entry in the "Name" column in Exchange. Still able to use the certificate and assign it to Exchange services and IIS. Certificate now also shows in Web Hosting in mmc. After that am also able to assign same Friendly Name to certificate in the Personal certificate store as in the Web Hosting store and once that is done certificate Friendly Name now shows in Exchange Certificates.

Bugs:

1) Lots of misinformation on the web regarding running of scripts to import into Exchange. Very poor advice in the manual to abandon the interactive interface for creating Exchange certificates and using the command line. All of that is completely unnecessary. The manual should emphasize use of the Interactive interface when possible, and the importance of exporting both the private and public keys into files during use of the Interactive interface, and then using the Exchange native tools to import the certificates in the ECP. The entire point of Lets Encrypt is to make it easy and simple. To get the largest number of people to use it, the easiest tools to use should be emphasized first in the manual.

2) Some more work needs to be done to the program so that when Windows Store is selected that the program states that the certificate will be inserted in Web Hosting certificate store accessible under the Computer Account, or it will be inserted in whatever store is defined in the settings file (if that has been modified) The store should be displayed. A warning also should be displayed that the server may need to be restarted to make the certificate show up.

3) The manual should put the automation into a separate section. Once a new user of the win-acme program successfully installs a Lets Encrypt certificate in their Exchange server then it is time to start discussing automation. Such as creating a script that renews the certificate and places it directly in the My store (which Exchange uses) and adding the commands to make Exchange assign the renewed certificate to services.

4) Need better documentation on how to extract the private key in the manual. There seems to be no way to do it with win-acme except during initial certificate generation even though a lot of stale documentation out on the web claims it can be once the certificate is saved in Windows Store. The certificate stored in ProgramData is password protected and no docs seem to show how to obtain the password used so that cannot be imported anywhere. Also the private key is marked Non Exportable so the Windows tool in mmc will not export it. It isn't the responsibility of win-acme to throw barriers up against an admin who wishes to do these simple tasks.

Hi @tmittelstaedt, sorry about your bad experience, but thanks for sharing it. I'm only going to respond to the parts that I think might be useful for future Googlers or win-acme, because some of it is rather out of scope.

Ran mmc and using certificate import COULD NOT FIND the certificate in ANY windows store.

It should be in the WebHosting store by default, as documented here: https://www.win-acme.com/reference/plugins/store/certificatestore

Ran Exchange ECP and certificate did not appear in the list of certificates.

I think Exchange only checks the My (Personal) store. You can configure that using the methods described in the link above.

Very poor advice in the manual to abandon the interactive interface for creating Exchange certificates and using the command line. All of that is completely unnecessary.

Not really and it's explained why too. You might argue that each and every setting should be available from the interactive menu (turns out that people don't like answering too many questions), or that there should be a special "Exchange" option there or something, which might be a good idea. But currently if you want a 100% working, automatically renewing certificate, this is the way to go.

The manual should emphasize use of the Interactive interface when possible, and the importance of exporting both the private and public keys into files during use of the Interactive interface, and then using the Exchange native tools to import the certificates in the ECP. The entire point of Lets Encrypt is to make it easy and simple. To get the largest number of people to use it, the easiest tools to use should be emphasized first in the manual.

I don't agree that doing stuff manually is the easiest. If you want to do it manually then why not buy a regular certificate and replace it once a year, instead of using an ACME client in a convoluted way every three months? Your time I think is more valuable than money you save with a "free" certificate.

Some more work needs to be done to the program so that when Windows Store is selected that the program states that the certificate will be inserted in Web Hosting certificate store accessible under the Computer Account, or it will be inserted in whatever store is defined in the settings file (if that has been modified) The store should be displayed.

That's a good idea, I'll look into that. It is already logged though. Running with --verbose to make that pop up on the screen is one of the first steps recommended for troubleshooting.

A warning also should be displayed that the server may need to be restarted to make the certificate show up.

You were messing around with a .der file without a private key manually, that required you to reboot. This doesn't apply to anything win-acme does.

The manual should put the automation into a separate section. Once a new user of the win-acme program successfully installs a Lets Encrypt certificate in their Exchange server then it is time to start discussing automation. Such as creating a script that renews the certificate and places it directly in the My store (which Exchange uses) and adding the commands to make Exchange assign the renewed certificate to services.

Again, automation is the point. If you just want to have a .pfx file to use for your own purposes, or just want to put a certificate into the computer store, there are also ways to achieve that. But those are different use cases so you have to look elsewhere in the manual, e.g. https://www.win-acme.com/reference/plugins/store/pfxfile.

Need better documentation on how to extract the private key in the manual. There seems to be no way to do it with win-acme except during initial certificate generation even though a lot of stale documentation out on the web claims it can be once the certificate is saved in Windows Store. The certificate stored in ProgramData is password protected and no docs seem to show how to obtain the password used so that cannot be imported anywhere. Also the private key is marked Non Exportable so the Windows tool in mmc will not export it. It isn't the responsibility of win-acme to throw barriers up against an admin who wishes to do these simple tasks.

You can enable the private key to marked as exportable in settings.json. This is disabled by default because it's the safest setting and most people don't care about exporting their private keys because they use automation.
You can get the password for the cache file from the program itself by showing the renewal details.
What you really should be doing when you want to have a .pfx file, without password or with a password of your own choosing, is to use https://www.win-acme.com/reference/plugins/store/pfxfile

Hope this helps you or anyone with similar concerns.

"I don't agree that doing stuff manually is the easiest. If you want to do it manually then why not buy a regular certificate and replace it once a year, instead of using an ACME client in a convoluted way every three months?"

I should have clarified it. Nobody reading the manual is an experienced win-acme user. The manual is read by newbies coming from a windows environment where a lot of stuff is spelled out and point and click. Automation using point and click is baloney so even Microsoft introduces them to powershell scripting gradually. I know a number of admins who work professionally as admins and do not know the first thing about powershell.

What the manual should be doing is starting with the manual interactive way of doing it. Then bringing in automation later. For a newbie to win-acme if they are an experienced powershell/scripting admin they are going to skim right over the manual to the automation section and start there. Otherwise the manual needs to hold hands through a successful cert issue and then if they decide later they don't like doing it interactively over and over they can advance to the automation section.

"You were messing around with a .der file without a private key manually, that required you to reboot. This doesn't apply to anything win-acme does."

I know that which is why I said MAY. The windows cert handing isn't the greatest in the world and this is the interactive interface I'm talking about which shouldn't be used regularly, right? Because of automation right? That's what you said. Adding a few extra hints may save someone a lot of time.

If you export both the private key (and set the flag so it's exportable) and the certificate into a pem file and import them into the exchange server using the ECP interface then they SHOULD show up immediately. The reason they didn't was I was importing the public certificate without a corresponding private key. It took restarting the cert store for windows to match that cert with it's private key and make it display. I assume the same thing would happen if someone used the mmc to copy a cert from one area of the store to the other - windows would not duplicate the same private key, it would just match both certs to the single private key. The way I did it was like getting from one side of the building to the other by walking out the front door, around the sidewalk to the back door and going back inside, instead of taking the hallway inside. Unexpected way to do it but you get to the same place. Since it was unexpected Windows had no understanding it was supposed to tie the cert into an existing PK until the server rebooted and the cert store must have checked as part of it's initialization routine.

If they export the keys to files instead of having the program use the API in windows to insert them into the store, then strange things like this can happen in Windowsland as they use keys. Remind them to reboot. It might just reduce the S/N ratio in the questions.

"You can enable the private key to marked as exportable in settings.json. This is disabled by default because it's the safest setting and most people don't care about exporting their private keys because they use automation."

Big disagreement on that. It is not that most people don't CARE it is that most people don't UNDERSTAND certs very well.

Consider the case where a small org has a connection to the internet behind a single static IP. Multiple servers behind that IP. One's a VPN server one's a mailsrver, one's a webserver. RDP on all of them. Maybe even more servers. Maybe they have 8 of them behind one IP with ports 3389, 3390, 3391, 3392 etc. forwarded.

They can do it your way and run win-acme 8x2 - 16 times, 16 different private keys, to get all their services on public/private certs. Or they can do it my way, run it once, put all of the different host/domain names into the cert, then put that same cert and PK into all 8 machines and tie all the services to it.

My way is a lot simpler. Yes, you have to figure out how to distribute renewal certs inside. Shouldn't be that difficult. All servers are part of the same network.

You have taken pains in the manual to bury the significance of the default being non-exportable. Once more, remember. This is Windowsland. Most of them are new to this, They are using LetsEncrypt because they don't want to drop $20 on a commercial cert that they don't know if they can even get working. Windows does not like to issue very good error messages that are very explanatory. They won't know why they can't export the PK from the cert they see in windows store when they can export the PK from the cert they bought from GoDaddy. They are ignorant. What do you think they are going to assume? They are going to assume something is wrong with the cert and that win-acme is busted.

I already stumbled over one of these questions on I think it was spiceworks's forum where the user said they were going to revert to the 1.9 version of win-acme because "I know it works" Emphasize the significance of WHY you are making the default non-exportable IN THE MANUAL. If you explain why people will accept it. Don't try sneaking it in or you just will piss people off when they figure it out and a lot of them may give up.

"What you really should be doing when you want to have a .pfx file, without password or with a password of your own choosing, is to use https://www.win-acme.com/reference/plugins/store/pfxfile"

Or even better install OpenSSL, and strip out the password myself. Then I can leave the random password you assign alone in the cache, and use the stripped .pfx file for whatever I want then delete it when I'm finished with it. And stick the random password in a file by itself marked "work to do" which even if a cracker snarfs down they won't know what the heck it is. Not to mention the fact that if I get pwned the cracker can just run win-acme and get the password if they want. Which they probably won't do since they will be too busy using my server as a mule to tell the world about their new baldness cure.

Some of this sort of thing gets ridiculous. a password inside a password protected file that's encrypted with another password stored in another encrypted file that's encrypted with a key that is saved in another encrypted store.

At some point it ceases being about security and becomes just plain silly.

Remind them to reboot. It might just reduce the S/N ratio in the questions.

In years of maintaining this software you are literaly the first person I've ever seen write about this. And it only happened because you were doing stuff in neither the default nor recommended way. Besides when you are manually messing about in certlm.msc or Exchange you should be following Microsoft docs, it's not this projects goal to educate people on the finer details of how that all fits together.

They can do it your way and run win-acme 8x2 - 16 times, 16 different private keys, to get all their services on public/private certs. Or they can do it my way, run it once, put all of the different host/domain names into the cert, then put that same cert and PK into all 8 machines and tie all the services to it.

That is not "my way" at all. I could get all of that working from a single automatic renewal. But I wouldn't have to export the private key, I'd use an installation script (Powershell), which would give me the path and password of the .pfx file in the cache.

You have taken pains in the manual to bury the significance of the default being non-exportable.

Yes, I spent hours figuring out the best way to hide that information. Look, I'm open for suggestions on how to improve things but I'm not really liking the cynical tone here. I will admit that this question comes up more often, so I will add a page to the docs explaining it.

Sorry about the cynicism I have found the entire public/private key CA infrastructure extremely irritating to deal with for years it is a textbook example of a simple idea that has been complexified - mostly by greedy CA's who want to awe people into overpaying. That's not your fault! But what it does mean is the finer details of how all this works are documented in little bits and pieces all over the web.

Let's Encrypt's site hands out no docs on using ACME clients instead referring people to acme client documentation like the win-acme manual. (as it should) Also since Lets Encrypt and the acme protocol does not fit into the paradigm of generating a CSR from the mailserver ECP interface and sending it to a CA, there is a documentation gap. This has been filled by a plethora of hand-holding instructions on the web and many use win-acme (probably because they know little about Linux) and unfortunately most of the ones I have found out there that deal with win-acme cover old versions, and are often rip-offs of some other site's win-acme recipe.

I understand anyone writing documentation needs to balance between too sparse documentation and too much. All I am saying is that as a newbie to win-acme, there's just a few simple additions that would have clarified how the software worked, and gotten me pushed up the learning curve a bit quicker as well as possibly some other people. I do appreciate the work involved in putting win-acme together!

Thanks! It's difficult to write documentation that works for all levels of users. We have people who barely know anything and need their hand held, people that want to know each and every detail and people that just need a little hint here or there when they get stuck. I've just added a section about private key management that might help people with similar issues: https://www.win-acme.com/manual/advanced-use/private-key-management

But I should also note that the site is open source and accepting pull requests, so if anyone feels a change here or there would be useful, feel free to PR: https://github.com/win-acme/win-acme.github.io

win-acme / win-acme

Blank Friendly Name in Exchange 2016 #1693