Certbot For Windows Bind To Port 80 Winerror (10013)

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. https://crt.sh/?q=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: mail.jbsbtech.com jbsbtech.com

I ran this command:certbot certonly -- standalone

It produced this output:Problem Binding to Port 80 [Winerror 10013]

My web server is (include version): Not applicable. I use 'standalone' certbot option to create a certificate

The operating system my web server runs on is (include version): Windows 10 Pro

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 login to Windows 10 Pro with an Administrator level User Account

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
Not Applicable.

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Certbot version 2.0.0

Thou shall use --webroot

Certbot is a very unixy thing, it wants port 80 to itself, and won't work if something else is using it.


These two hostnames have very different IP addresses. While not impossible, it's probably difficult to obtain a cert for both hostnames from the same server.

Are you running Certbot as administrator? If so, then there probably is something listening on port 80..

There's a website running on the IP address of jbsbtech.com, but that's probably not your server, as I'm seeing a GoDaddy parking page.


Port 80 should not be used anywhere else. I have Port Forwarded Port 80 to Windows computer which is running Administrator Command Prompt command: certbot certonly --standalone

I use McAfee Firewall on the Windows computer running certbot. Port 80 has been opened for TCP protocol for all PCs.

This command is supposed to produce a Certificate without installing it into webserver. It is supposed to spin up a temporary webserver to process the Certificate Request.

It fails the challenges with the failure to Bind to Port 80 [Winerror 10013]. It states an attempt was made to access a socket in a way forbidden by its access privileges.

Yes the Domain jbsbtech.com is parked on GoDaddy. There is an 'A Record' on that Domain for mail.jbsbtech.com which is the IP Address for the Local Network which contains the computer which runs an Email Server the Let's Encrypt Certificate will be used for.

There is something listening on port 80.

❯ curl -IL mail.jbsbtech.com
HTTP/1.1 404 Not Found
Content-Length: 315
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Wed, 25 Jan 2023 11:56:07 GMT
Connection: close

I have been getting Let's Encrypt certificates using a Synology NAS DSM utility which runs on linux for these two Domain Names for years. I am forced to use Certbot because the NAS has had a hardware failure and I cannot use its utility until I get it replaced. So I know it is possible to have a Certificate for these Domain Names though in this case the Email Server mail.jbsbtech.com and the Website which is also used are both in the same Local Network and do not run on GoDaddy's hosting service.

If you have no specific need to use certbot, use a Windows specific client. You won't have these headaches.


I am using Certbot for Windows which is supposedly an approved utility to produce Certificates on Windows. Therefore, unless I'm not understanding the meaning of a client I believe this is what you stated I should use since it is for Windows.

It is approved. It's just not very comfortable. It will work, but... it's not software for Windows, it's Unix software that also runs on Windows.

WACS and Certify come to mind as alternatives.


There is also a Win-Acme client which some supposedly have gotten to work.

Yes, that's a name for WACS :wink:


Thanks I was suspecting that was what WACS might have been.

1 Like


But as far as the problem with Certbot for Windows, as far as I can tell from the Log Entries, it appears that some plugin for the Challenges might be missing or possibly need to be added.

1 Like

From what you posted, it looks like something is listening on port 80 and that causes a conflict.

It's a known issue and originates in the fundamentally different way Windows and Unix handle TCP daemons. On Unix only one Daemon per port is allowed, and certbot works that way. On Windows, sharing is allowed, and Windows specific clients do share with iis.



In this case, all TCP Port 80 traffic is Forwarded to this one Windows Computer in this Local Network. I'm also fairly certain there is no other Port 80 applications running on this computer because up until I started using Certbot for Windows I had TCP Port 80 traffic forwarded to the Synology NAS. If something else was listening on Port 80 I would believe there would have been a problem long before this.

I'm not really an expert in this but I'm suspecting it has something to do with the socket permissions rather than Port 80 itself. Also as far as I understood Certbot for Windows, Let's Encrypt Certificates I thought were returned on Port 443

Also, I have IIS uninstalled and still get this error. I uninstalled IIS after getting this error to see if there would be any difference.

I, also, found information which indicated this Bind Error is a fairly common error.

Something is listening on port 80 for mail.jbsbtech.com

I mean: it's answering with a proper 404 error, that's an http server working.

Maybe it's your webmail system? I have no idea and I'm not even sure how to find out. (But I know that looking for the proper documentation is key -- I'm not a Windows expert)

That depends on the challenge type. http-01 uses port 80, tls-alpn-01 uses port 443 and dns-01 uses port 53.


I do not use a webmail system so there should be no Port 80 involved in this respect. I use Outlook Email Client.

See if this can be useful:



This might be helpful to you from the Certbot Log

2023-01-25 03:10:36,203:DEBUG:acme.client:Storing nonce: C878sNei-RIzvvYDNml29U3PljQ7U8fggnwIQIkmFoVBxtc
2023-01-25 03:10:36,204:INFO:certbot._internal.auth_handler:Performing the following challenges:
2023-01-25 03:10:36,204:INFO:certbot._internal.auth_handler:http-01 challenge for mail.jbsbtech.com
2023-01-25 03:10:36,205:INFO:certbot._internal.auth_handler:http-01 challenge for jbsbtech.com
2023-01-25 03:10:36,205:DEBUG:acme.standalone:Failed to bind to :80 using IPv6
2023-01-25 03:10:36,206:DEBUG:acme.standalone:Failed to bind to :80 using IPv4
2023-01-25 03:10:36,208:DEBUG:certbot._internal.error_handler:Encountered exception:
Traceback (most recent call last):
File "C:\Program Files\Certbot\pkgs\certbot_internal\plugins\standalone.py", line 79, in run
servers = acme_standalone.HTTP01DualNetworkedServers(
File "C:\Program Files\Certbot\pkgs\acme\standalone.py", line 219, in init
super().init(HTTP01Server, *args, **kwargs)
File "C:\Program Files\Certbot\pkgs\acme\standalone.py", line 122, in init
raise last_socket_err
File "C:\Program Files\Certbot\pkgs\acme\standalone.py", line 97, in init
server = ServerClass(*new_args, **kwargs)
File "C:\Program Files\Certbot\pkgs\acme\standalone.py", line 209, in init
File "C:\Program Files\Certbot\pkgs\acme\standalone.py", line 201, in init
super().init(*args, **kwargs)
File "socketserver.py", line 452, in init
File "http\server.py", line 136, in server_bind
File "socketserver.py", line 466, in server_bind
OSError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions,

Also while this Certbot for Windows may be approved, I do not trust its usability because the installer link for this indicates it is a Beta version. The instructions are also inaccurate at least to the extent that it states that Cerbot for Windows would be installed into Program Files (x86) but it was actually installed into Program Files as it is actually a 64bit application. So I'm skeptical that this utility really was tested properly.

During handling of the above exception, another exception occurred: