Hello.
I have a WebSocket server running on a specific IP address that should operate over HTTPS (WSS).
How can I obtain a certificate for this IP address? There is no website on this IP, it is not needed.
Hello @andrys, welcome to the Let's Encrypt community. 
Let’s Encrypt offers Domain Validation (DV) certificates; not IP Address Certificates.
Most of the ACME Clients have the ability to spin-up a temporary webserver for HTTP-01 challenge of the Challenge Types - Let's Encrypt; however there is the DNS-01 challenge which does not require a webserver for validation.
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
Thank you for assisting us in helping YOU!
2 Likes
I have Windows Server 2019 installed on a specific IP address. It only hosts a WSS server, so it doesn't require a domain name because connections are made via the IP address. Here's an example of a connection:
new WebSocket('wss://192.168.1.188:3300'); (using a local IP address for demonstration) Where 'WSS' indicates that the connection will occur over a secure protocol
Then please see https://letsencrypt.org/docs/certificates-for-localhost/
2 Likes
Are you planning on hosting this to the Internet?
[if so, then you will require a domain name]
3 Likes
You can't get a certificate for an IP address through let's Encrypt. Just assign an actual subdomain on your real domain like api.yourdomain.com (or whatever you like) and get a real certificate, it's easier.
If you did it using https://certifytheweb.com (for example, which I develop) you would open up port 80 so it can host the http challenge, then New Certificate > add your domain(s), Request Certificate. Once you have a cert use a deployment task like Deploy to Generic Server under Tasks, and export the fullchain pem file and the private key pem file somewhere your WSS server can see it, configure your WSS to use those files and hey presto!
You may need to restart your server periodically to make sure it picks up the latest cert, or build in a periodic certificate reload. I'm assuming with all this that your server is node or something similar and not just IIS.
2 Likes
Yes, that's correct. I've linked the domain name his-name.com to my IP address and tried to obtain the certificate again. But again, I couldn't do it. It's just some kind of trouble.
(I've associated the IP with the domain name; there won't be an actual website)
ERROR:
Input the webroot for his-name.com: (Enter 'c' to cancel): c:\certbot Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems: Domain: his-name.com Type: unauthorized Detail: 185.68.21.169: Invalid response from http://his-name.com/.well-known/acme-challenge/_f2so4QE2SkwTNk9wiZo_Z7q7851kJfY1x1jdZ3_bwg: 404 Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet. Some challenges have failed. Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile C:\Certbot\log\letsencrypt.log or re-run Certbot with -v for more details.
You may need to use standalone instead of webroot.
3 Likes
As @rg305 says if you're using Certbot you'd probably need to use the standalone mode (which runs a temporary port 80 web server for the http challenge response), webroot only works if you have a webserver process on port 80 and it will serve the files itself.
3 Likes
If there was a 404 file not found error returned, then SOMETHING is answering on port 80... Thus standalone will probably not work either due to the fact it can't bind to port 80 or the IP address or port mapping or something similar is incorrect.
Is his-name.com actually the literal hostname in question? Because there's an IIS webserver listening there.. Sooooooo... Either the hostname is incorrect, the IP address is incorrect or the "there is no website on this IP" was incorrect.
Also insert Certbot for Windows is deprecated template here
3 Likes
In the Windows world, port 80 can be shared.
2 Likes
@Osiris good point. Just clicked the link, it's IIS that's responding and therefore certbot standalone won't work because windows already has a port 80 binding.
@andrys see my instructions above on how to use Certify The Web - this will setup certificates for IIS and also gives you the option to export to other services (express js etc). Note that nodejs can use PEM components or the PFX/P12 archive format (Install a certificate on Node.js). You could also use other clients like win-acme etc if you prefer.
The first step is to get your certificate, the second step is to automate your deployment.
[You can also optionally reverse proxy in IIS back to your node service, exposing just your IIS service to the internet, that way the https is handled by IIS/windows and you don't have to also configure your cert in node at all]
2 Likes
Hello friends. Yes, I launched node.js, but I couldn't bind it to port 80, so I set it to 3300 for testing, it's visible over the network. Now the problem is to bind it to port 80. http://his-name.com:3300/
Can it be used behind a proxy?
1 Like
I did not specify certbot.
[quite the opposite]
I was rather hoping they would use standalone with a real Windows client.
One that can share port 80; Like: https://CertifyTheWeb.com/
3 Likes
Also with Python (Certbot) or just IIS? 
I'm not familiar with Windows, so I'm (slightly) curious to know 
1 Like
Hello friends. I'm actually a programmer, not dealing much with servers, so this topic is new to me. I need to solve this task with as few problems as possible. I have Windows Server 2019, and I need to run node.js on it to work with WSS. There won't be anything else, but as I understand it, access to WSS will be through a domain name, so I had to set it up. Next. Now I need to get a real certificate to test the code. HTTP is running on port 3300, it needs to run on port 80 so that I can then get the certificate.
Not with python or at least not in the way the Certbot uses it. In Windows the http/https support is (optionally) handled by the kernel level http.sys and TLS is managed by the Schannel subsystems. IIS works on top of http.sys (and schannel) to provide a web application server (e.g. all the additional stuff you need like handlers for PHP or asp.net etc), plus a management layer/api.
If an app directly binds to port 80 though, nothing else can. So Port 80 gets used up either as soon as you have any http enabled sites in IIS (or any other http.sys aware listener), or if you fire up Apache/nginx or a custom port 80 listener (python, node etc) and the two don't co-exist but technically they probably could if they wanted to.
3 Likes
You have installed IIS and you have a default website running on port 80, you just need to look at http://his-name.com/ to see that, HTTP is port 80 by default, that's why you don't need to specify the port in the URL.
To free up port 80 you can stop IIS or delete the default website. The advantage of keeping it is that it could make it easier to validate your certificate domain. You could just point Certify The Web (or win-acme or Posh-ACME etc) at your IIS site and generate a certificate and it will take care of http validation.
To get a certificate using your own service via HTTP validation you need to automatically prove to Let's Encrypt that you control the domain, that involves your server responding to ./well-known/acme-challenge/ requests, so to do that with your node/express server you would configure your application to be able to server static files that are placed under the /.well-known/acme-challenge path (how you do that is specific to your choice of web server) and tell your ACME client to put the generate challenge response files there.
You can test this out by putting a test text file (with no .txt filename extension) under your application path so that http://his-name.com/.well-known/acme-challenge/test works
If you instead want to host the http challenge via your own node service, all ACME clients generally have an option for you to specify the root path of your website (in this case your express app), for example if you were using Certify The Web to do this, you would set the Site Root Directory under the Authorization tab and the app would automatically generate the ./well-known/acme-challenge path under that directory, and you can test it with the Test option.
Keep in mind that you probably won't be using port 80 normally, so I don't see much of a problem just keeping IIS for the port 80 stuff (and helping get your certificate). WSS is Web Sockets over HTTPS so it defaults to port 443.
Here is an article discussing how you could just use IIS as the front end for your service but keep express running on a higher port behind the scenes. This simplifies your certificate renewals (you otherwise need to prepare your certificate files where express can see them, then restart express to pick them up).
IIS As Reverse Proxy To WebSocket Server | by Adrian Jenkins | Medium
If it feels like it getting complicated, it's because this is actually complicated. At the end of the day you are trying to achieve two things:
- getting a certificate (which involves proving you control the domain for it usually either via HTTP validation of DNS validation)
- applying a certificate to your service (preparing the files where your service can see them in the format it wants, then reloading the cert or restarting your service).
It's extra complicated because you are using two different web server stacks (IIS/http.sys and express/node), but there are advantages to that approach.
2 Likes
When will there be nothing else?
Right now: IIS is listening on port 80.
Do you plan on removing IIS?
Not exactly.
It sounds like you are implying that whatever is on 3300 also needs to be on 80.
It doesn't (have to be that same thing).
Yes, something must be on 80 - but it doesn't have to be whatever is on 3300 now and it doesn't have to run all the time [only when needed].
That said, whatever is on 80 only really needs to be there to answer the challenge requests [then and only then]. Which means, it could be the ACME client itself that spins up a temporary web service to answer the HTTP request [standalone mode].
That said, you already have IIS running [who know why] and it could facilitate the required HTTP response.
3 Likes