Mydomain.cloud.ddns.net:9443

How do I generate certificate for VM2?

image

VM1: mydomain.cloud.ddns.net (works)
VM2: mydomain.cloud.ddns.net:8082 (Invalid Domains)

Hi, so I think the problem you have here is that the default domain validation method is http on port 80 and Let’s Encrypt don’t let you vary that port (you can redirect from port 80 but you must at least respond), so VM1 is answering all of the http challenges from Let’s Encrypt.

The other option is DNS validation (i.e. scripting updates to your DNS TXT records in order to answer challenges from Let’s Encrypt) but you do need to use a DNS provider supported by the app or do the DNS scripting yourself.

Another option is to request the certificate on VM1 when using the Show Advanced Options > Scripting option to deploy the certificate to VM2. See https://docs.certifytheweb.com/docs/script-hooks.html - You can either script the certificate import and binding update on VM2 (perhaps as scheduled task or remote script) or configure VM2 to use Centralised Certificate Store and keep the store as a share on VM2 then use VM1 to copy the new certificate to that CCS store UNC path. Yes, it’s complicated.

Future versions of Certify The Web will have more built in options for dealing with these scenarios but I’d try the DNS validation option if you can as that’s the easiest, followed by the scripting + CCS store idea.

As an aside, by default Certify The Web uses it’s own built-in http challenge server that spins up temporarily on port 80 (it uses http.sys so it interoperates with IIS), listening for /.well-known/acme-challenge/ requests, so technically you don’t need IIS at all but you do need port 80 open and traffic being direct to the correct server (which you can’t do in this configuration because you wouldn’t know which server to direct traffic to).

If configured in a certain way, you could do this with network shares and symbolic links.

For configuration, you would need to have both IIS servers do the .well-known path serving and not the built-in temp server. Once you can verify that both VMs can serve files from that path, delete the folder on VM2; then create a symbolic link in its place pointing to the same folder that is used on VM1. VM1 will need to be sharing that or a parent folder using standard Windows networking. You may need to do additional work to make sure that VM2’s machinename$ account has write access to VM1’s folder. Though if VM2’s IIS instance or app pool is running as a different user, you may have to allow that instead. If you’re not using AD, you may need to approach the folder sharing slightly different. (or you could completely unsecure the share, but that doesn’t sound great)

Once done and working… Certify on both VM1 and VM2 will write challenge files to the folder on VM1 and VM1 will serve the files on port 80 for both VMs.

–EDIT–
Now that I think about it… IIS on VM2 doesn’t need to be configured to serve the challenge responses at all. Certify on VM2 just needs to be pointed to the share on VM1 and told that the path belongs to a specific site on VM2. You don’t need the symbolic link in this case… just the share on VM1 that has access to the .well-known folder.

1 Like

@jljtgr I ended doing what you said, except ceritfy did not write on the shared folder (I’ve checked the permissions). So when a file is created on the acme-challenge of VM2 I automatticaly move it to the shared folder.

Well, it’s good that you got it working… though it’s strange that Certify could not write the files over the network share. You’re not using mapped network drives are you? Those won’t be visible to Windows services. If you care enough, you can try using ProcMon to diagnose why Certify isn’t able to write the files… if Certify’s logs don’t give any clues.

1 Like

Yep “Acess Denied”. Turns out that the Certify Service was not running with admin account. So I changed and it worked!!! Thanks!!! :grinning: