-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Management UI error icon bug #14
Comments
As far as I know, the root cause is that the IIS manager GUI requires some very specific inner format of PFX files and the library I use produces different format. I didn't ventured into this further, as AutoACME can display all the required data and my resources are limited. However, I would appreciate if you would look into it. I think that first thing needed is research -- what exactly the IIS Manager GUI requires. |
Things are getting a bit interesting on my end. Tried to figure out what could be wrong, as promised. It seems that the GUI is parsing the certificates by importing them into a temporary certificate store. That happens using something similar to the following code:
Docs for the unmanaged If the resulting I realized there is impersonation going on while these methods are being invoked and removed the impersonation. The error icon went away and the PFXImportCertStore was able to parse certificates without any issues. That gave me some idea, I went ahead and set my Administrator user as the centralized certificates feature's username, also set its password of course. Suddenly certificates started appearing correctly. I went ahead and set the user back to I think I can say that there is something wrong with the impersonation because as soon as the user is impersonated, the certificates cannot be imported using the However, the same certificates and the same impersonation logic works as soon as I import one of the certificates generated by AutoACME to the certificate store manually and then export it, that exported PFX works fine when I drop it to the certificates directory. The questions/thoughts I have now are;
Please let me know what you think. |
By the way, the only difference I could find between a working (imported / exported) and a non-working certificate was the "Key provider" reported by DigiCert app. Working: Microsoft Enhanced Cryptographic Provider v1.0 However, I cannot say that it does not work because the key providers are different. Also the file sizes of the PFX files but I don't know if that really could be of a problem. Might not be related to the subject but does the current version have a switch to include the full chain within a generated certificate? If not, would you mind to add it or mind if I make a MR and add that a |
First, thank you for your analysis. I'm afraid there isn't anything I can add to it, since unmanaged Windows programming isn't my area of expertise. It looks to me like the problem lies in the IIS Manager, not in the PFX files. Maybe it's a good idea to contact someone from IIS team. As MVPr, do you have the contact, or should I find someone and connect you two? |
Regarding the full chain: I think it should be added in configuration file, not as a command line switch. I can do it, but I'm in the US right now and have not good Internet access. Feel free to make your own fork, or wait till next week when I'll return. |
Enjoy the summit! :) Just opened a new issue at the IIS.Administration repo. Let's see what they say. If that does not help, I might ask you to connect me with a member of the team as I don't have contact with one. Regarding the full chain support; it is your call. However, my experience says that the full chain might be necessary in some cases and not in others. So I thought it would be a better idea to provide it as a switch rather than a configuration parameter. But again, your product, your call, I respect that. |
I believe that full chain yes/no is basically a system-wide issue. I try to keep number of commandline switches as small as possible, becaucse the entire thing is supposed to be run non-interactively anyway. |
Quote from microsoft/IIS.Administration#182 (comment)
@jimmyca15 We can certainly reproduce this issue. Just as a side-note, I initially thought the issue was related to AutoACME project but all the analysis I made basically has the following results in short. If it was AutoACME related, the certificates generated by AutoACME should be completely invalid. However, they are not. They work fine to secure the related bindings, browsers (and other clients) recognize the SSL certificate just fine. I can even import that "broken" certificate into user and machine stores without any issues. What is more, if I change the user to Administrator, the very same certificates are displayed just fine anyway. Even further, when a certificate is displayed as broken, I can double click it on the inetmgr.exe and see the details of the certificate. One very important and very interesting thing to note here is that, I mentioned that the impersonation works fine when I set the user to Administrator but it does not work if I add my certificate user to the Administrators role. Finally, in order to reproduce this issue, please follow the steps below.
First of all, you have to configure AutoACME which is a real quick thing to do: https://github.com/ridercz/AutoACME/wiki/Getting-started-with-AutoAcme Then you have to generate a certificate using the following command.
Double clicking the broken certificate displays the details just fine: The same screen when the CCS identity is set to my own user ( However, as I mentioned, adding CentCertUser to the Administrators role (for sake of testing) does not seem to fix the display issue. |
Automation to automatically add the certificates to the account configured in IIS:
|
This is completely unrelated to this issue and AutoACME in general. Yes, it's possible to import certificates into personal stores of any user, but it makes no sense. To use certs for HTTPS, they have to be imported into machine store, either to "Personal" or better "Web hosting". To avoid necessity of managing these certificate stores, AutoAcme uses the Centralized Certificate Store approach, where it's enough to just place the PFX file to designated folder, if it has a correct name. This issue is about minor problem, that the management GUI (and only the management GUI, nothing else) shows them incorrectly. |
Hi Michal,
Being a former ASP.NET MVP and an rMVP now, I appreciate the AutoACME project and the time you put on it. Thanks for sharing.
I realize you have the following note on the documents:
I, personally, don't mind a UI bug but that screen gives a very important information about certificates which is when they would expire.
Are you aware of the root cause of the bug? Is there anything I can do to help you to fix it? A PR, research, debugging?
The text was updated successfully, but these errors were encountered: