Management UI error icon bug about autoacme HOT 11 OPEN

Hey CoskunSunali,

I just ran into the issue that you described (and thank you! for all the great documentation), and was able to resolve the issue for me.

Similarity to problem described above:

The key piece of information that lead me down the correct solution was that when Centralized Certificates was configured to use my personal account to read the shared SSL folder (Central Certificates Folder), it was able to correctly read the Let's Encrypt generated certificates. (My account is a local administrator which can see all certificates registered on the computer.)

However, when I switch the configuration of Centralized Certificates to use the "CentCertUser" you described above, it was no longer able to read the Let's Encrypt generated certificates. (And the UI showed the "Bad Data" error message)

Issue:

The Let's Encrypt certificate requires 3 certificates to fully validate it's chain. The "CentCertUser" only has access to 2 of these certificates.

If you import the certificate into the Local Computers Trusted Root Certification Authorities folder, it will import both the (1) certificate that Let's Encrypt generated for your site and (2) the DST Root CA X3 certificate (it may be possible that Windows ships with this certificate). However, the Let's Encrypt Authority X3 certificate does not get imported.

(The PFX I was importing from had all 3 certificates built into it; and I tried all the different checkboxes during the import process. I just couldn't get Let's Encrypt Authority X3 into the Trusted Root Certification Authorities folder under Local Computer.)

Solution:

The solution is to import all of the certificates in the chain into the "My" store for the "CentCertUser" account.

1. Open up mmc as "CentCertUser" (my apologizes for the detailed explanation if you already know what to do)
   1a. In the start menu, type in 'mmc.exe' and right-click to go to 'Open file location'. (C:\Windows\System32)
   

1b. On 'mmc.exe', shift-right-click and 'Run as different user'. Use the "CentCertUser" account.

2. Use 'Add/Remove Snap-in...' (Ctrl+M) to add 'Certificates'. You should not be given an option at this screen; it should automatically add 'Certificates - Current User'.
   

3. Under Personal > Certificates, right-click and choose All Tasks > Import ...
   

4. Once you've imported your certificate, you should see all 3 certificates imported.
   

5. Now that the Let's Encrypt Authority X3 certificate is available in "CentCertUser" Local\My certificate path, it should be able to correctly validate and load your Let's Encrypt generated certificates.
   

HTH

from autoacme.

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.

from autoacme.

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:

IntPtr ptr = UnmanagedMethods.PFXImportCertStore(ref crypt_data_blob, privateKeyPassword, 0x8250)

Docs for the unmanaged PFXImportCertStore method: https://msdn.microsoft.com/en-us/library/windows/desktop/aa387314%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

If the resulting ptr equals IntPtr.Zero, the last error is taken using Marshal.GetLastWin32Error() and then an exception is thrown with that last error, which is Bad Data in our case.

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 CentCertUser and error icons came back.

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 PFXImportCertStore method, even though the impersonated user has access rights to the certificates directory and the certificate files.

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;

1. If there is a problem with the impersonation, why would import/export/copying a PFX file manually fixes all the issues, the impersonation is still there.

2. If there is a problem with the way you generate the files, why would they work fine if I change the feature's user identity.

Please let me know what you think.

from autoacme.

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
Non-working: Microsoft RSA SChannel Cryptographic Provider

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 --full-chain switch that sets the FullChain property accordingly at https://github.com/ridercz/AutoACME/blob/master/Altairis.AutoAcme.Core/AcmeContext.cs#L98

from autoacme.

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?

from autoacme.

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.

from autoacme.

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.

from autoacme.

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.

from autoacme.

Quote from microsoft/IIS.Administration#182 (comment)

@jimmyca15 commented 8 hours ago

@CoskunSunali

Do you have a way to definitively reproduce this issue? You mentioned you think it has something to do with the impersonation involved in reading the certificates. Is there something special about the account that you are impersonating with?

@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.

1. Create a new Windows user (e.g. CentCertUser) and assign only the "Users" role.

2. Create a directory to store the PFX files. In my case the directory is a folder on local computer's drive D: full path being D:\Certificates. Permission inheritance is disabled and only the necessary identities has access to the directory.

3. Enable CCS.

4. Create a new website on IIS and create the HTTPS binding.

5. Use AutoACME to generate a certificate for a given website on IIS.

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.

autoacme addhost example.com

6. Follow to the CCS screen to see the certificate.

Double clicking the broken certificate displays the details just fine:

The same screen when the CCS identity is set to my own user (Coskun, an administrator)

However, as I mentioned, adding CentCertUser to the Administrators role (for sake of testing) does not seem to fix the display issue.

from autoacme.

Automation to automatically add the certificates to the account configured in IIS:

        private void AddLetsEncryptAuthoritiesToAccount(
            string userName,
            string password,
            string domain)
        {
            Advapi32Extern.LogonUser(userName, domain, password, 2, 0, out var accessToken);

            List<string> certificateUrls = new List<string>();

            certificateUrls.Add("https://letsencrypt.org/certs/isrg-root-x1-cross-signed.pem");
            certificateUrls.Add("https://letsencrypt.org/certs/lets-encrypt-r3.pem");

            List<X509Certificate2> certificates = new List<X509Certificate2>();

            foreach (var certificateUrl in certificateUrls)
            {
                // Download the certificate
                WebClient client = new WebClient();
                byte[] certBytes = client.DownloadData(certificateUrl);
                certificates.Add(new X509Certificate2(certBytes));
            }

            WindowsIdentity.RunImpersonated(accessToken, () =>
            {
                X509Store userStore = new X509Store("My", StoreLocation.CurrentUser);
                userStore.Open(OpenFlags.ReadWrite);

                foreach (var c in certificates)
                {
                    userStore.Add(c);
                }

                userStore.Close();
            });
        }

from autoacme.

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.

from autoacme.