Clearification on usage of SSL certificates in Devolutions Gateways from Windows Certificate Store
Clearification on usage of SSL certificates in Devolutions Gateways from Windows Certificate Store
Hello Devolutions community,
today i chagend my SSL certificates on my Gateways and discoverd you can now load SSL certificates from the Windows Certificate Store. I had a little bit of an issue getting it working, but i figuerd it out in the end. After the selection of the SSL certificate in the Console i got an SSL error on the Gateway and no details regarding the used SSL certificcate where shown. I checked my settings via the console again and everthing was correct. After that i checked, if the used service account is allowed to read the private key of the ceritifcate and the required permission was missing. In my case the "network service"-account had no read permission the used certifcate. I added the required permission afterwards in the mmc for computer certificates.
I thought i share this scenario, because unfortunaly this use case right now is not in the documentation yet. Maybe this thread will help someone.
I alse would recommend setting the required permission via the console on the ssl certifiacte automatically, if it is technical possible.
If you have further questions, let me know.
Cheers,
Markus
All Comments (3)
Hi Markus
Thanks for the feedback; indeed the NETWORK SERVICE account needs read permissions on the private key of the certificate. I'm glad you figured it out
Actually this case is documented here. If you have some suggestions on how to improve that we would welcome them.
This is a somewhat common issue and we're looking at ways to make this problem more discoverable. The latest versions of Gateway call this problem out at install time - although that's only visible if you're doing a vanilla install, not via the Console. The Gateway itself will also report this error in it's logs at start time, but that's also not very visible unless you know what to look for.
My current thought for improvement would be a PowerShell cmdlet that can be run as an administrative user to check for and fix common problems like this. What do you think?
Kind regards,
Richard Markievicz
Hello @Richard Markiewicz
thanks for the feedback.
Great to know that my use-case is documented and sorry that i overlooked it.
I like the idea for fixing this via PowerShell also and maybe you can provide a script for that in the mentioned documentation. What i personally whould prefere is to see is that the Console adding the user, used by the Gateway, automatically to the used certificate with read permission on the private key. If this is technically not possible a warning whould also be nice when installing/editing the Gateway via the Console.
This suboptimal feedback to the user is no issue at all if you know about this circumstance. For me its just little QoL-thing which could use some improement and i wanted to let you know.
Cheers,
Markus
Hello Markus
Right on. Actually the main place where we hit this is now, many users are using LetsEncrypt / ACME to automatically rotate short-lived certificates. Users find that the setup is working, and then ACME rotates the certificate but if they got a new private key, then the permission is not added and their Gateway fails. So the first step is to add it to the PowerShell module so it can be used as a post-update hook when ACME rotates the certificate. The next step will be, as you say, to detect and/or automatically fix that via the Console. Since the Console drives the Gateway configuration through PowerShell, we'll do the first part... First :)
We have a ticket open for this; I'll link it to this forum thread so we can update you once it's corrected.
Thanks and kind regards,
Richard Markievicz