The main limitation of the community version that I’m aware of is a maximum of (5? 10?) certificates on a single server. Nothing else inside of the program is limited.
I don’t know much about Remote Desktop deployment, but adding a certificate to the Windows cert store is a basic function that happens before post deployment tasks come into play. The certificate isn’t a specific file format because the Windows cert store is not a collection of files.
Making RD use the new certificate in the store sounds like a post deployment task. You might want to look at other forum posts for suggested courses of action. I’ve seen it brought up a lot and it sounds like the only pitfall is finding a time to restart the service to use the new cert. You can’t tell Certify what time of day to attempt renewals because it must be able to reattempt failures spaced apart.
It sounds like you’re used to generating certificate requests and installing certificates you get emailed back.
The main thing you have to understand is that Let’s Encrypt will require a handshake through port 80 of the IP registered to the domain name you’re requesting for. This is a strict requirement that happens every renewal, so you must keep it in mind when generating certificates for non-web services. If you do not currently have anything on port 80 to handle the request Certify can spin up a temporary HTTP server to respond to the request then terminate.
If you can’t use port 80 at all, you might have to use DNS TXT records to do domain validation. This is IMO more complicated depending on your DNS provider.
As @jljtgr says the community edition is limited to 10 managed certs but that currently the only app limitation. You also don’t (officially) get access to the support ticket system without a paid license, but you can still ask questions here
I would start by using the app to fetch a certificate for your hostname.domain.com domain/subdomain as required for your service, then use that cert to play with the deployment tasks to get the scripting/export that you want. I would also recommend working on a test server, but failing that I would leave experimenting with the deployment tasks until you have scheduled maintenance.
We do have a built in RDS task but I find that can mean one thing to one person and a whole can of worms to another, depending on the complexity of their deployment, and sometimes people need their own scripting (which you can also do).
You can use many deployment tasks and there are several export options (Deploy to Generic Service is one, Export Certificate is another), for custom stuff you can usually use a couple of Export Certificate tasks to generic to combination of files you need, most commonly (when not using the PFX) this is the private key file, your domain certificate and a file for any intermediate certs - because certs are signed with certs, which are signed with certs
Thank you very much for all your responses, I really appreciate it.
Last night I had been a bit brave and installed the application to have a little play around. Surely you guys are correct advance features are available for deployment including deployment for RDS. Correct me if I am wrong but I do not think additional powershell scripts will be required to install the certificate into RDGateway, advance deployment option will be enough.
I carried out all the configuration & did a test, all test came out OK, but stopped at Requesting Certificate coz I wanted to know what responses I am going to get from you chaps.
The server I have RDS configured on is 2019 with powershell version 5.1. The issue is with RDS HTML5 Webclient, the certificate has be in in .cer format. This means when the renewal happens I need to schedule a task to run a script to first convert the renewed certificate into .cer then then import into machine certificate store, @jljtgr has rightly mentioned about timing issue.
Excuse my ignorance but I have not read anything here or on other forums on how to automate the renewal process for HTML5 Webclient. This is the bottleneck I have now come across in use of the application.
I am going to dig a bit more in today and see if I can find a solution.
I don’t think this is really the case. Certify will use Windows APIs to install the certificate into the machine certificate store directly where it can be selected. There are random PFX intermediary files that are stored in Certify’s ProgramData folder, but there should be no reason to convert them to any other format to use it with 1st party Microsoft products. I would be shocked to hear that any RDP implementation would avoid this.
For example, for IIS websites, Certify will import the certificate into the store and set the HTTPS binding of the selected site to that imported certificate. It doesn’t use any cer/crt/key exports in this process.
That said, you certainly can make a post-deployment task to do that… I just think there is no need unless the RDP server scripting thinks it is necessary. (not your previous workflow)
As far as I am aware when configuring the deployment properties of RDS you can only import certificate in pfx format. If you want HTML5 version of web working then you follow the steps in the guide you are referring step 1. On the RD Connection Broker server, obtain the certificate used for Remote Desktop connections and export it as a .cer file.
I am going test this entire process on a test server first make sure i can automate the entire process then use it in production.