Renewal for LE for IBM WAS fails

Hi good day!

I am trying to renew our website's ssl but i got this error 31mSome challenges have failed, I am trying to renew the ssl manually. please advise.

My domain is:

I ran this command:
certbot certonly --force-renew -d

It produced this output:

My web server is (include version):

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


1 Like

Welcome to the Let's Encrypt Community, James :slightly_smiling_face:

Something is blocking access to over port 80. Try running this command, which will pause and await user input before trying to verify the challenge:

certbot certonly --standalone -d "" --debug-challenges

Once paused, you should be able to continue debugging from there.

This will help you to be able to see the status of your ports:

1 Like

Hi Griffin,

Thank you for your reply, I have ran the commands you suggested but I don't see any additional details of the issue. I also allowed traffic for port 80 on our security group.

I also cannot access the link you provided


1 Like

Hi, port 80 may still not be open. There are potentially several firewalls to consider:

  • Windows Firewall (allow tcp port 80 incoming)
  • Your VM hosting (cloud or on-premises) network settings
  • Your network firewall (if applicable)

Hi Webprofusion,

yeah, I think the firewall did not allow port 80 for incoming traffic.
however , I got an Unauthorized errorafter I allowed port 80




Ok, so the second problem is that WebSphere's web server may be using port 80, so it's not available for certbot to do standalone challenge responses. If you don't need http to work for WebSphere you may be able to disable that in WebSphere, or alternatively stop WebSphere's server, run your renewal, then start WebSphere again.

I don't know enough about how WebSphere works to tell you exactly what to do unfortunately and I'm sure the configuration can vary depending on various factors. I'd assume you can also use IIS etc as a front end server for WebSphere so it depends what you're currently using.

If WebSphere lets you put documents in the website path and server them then perhaps you could use the webroot validation method: User Guide — Certbot 1.16.0.dev0 documentation

Alternatives also include using DNS validation instead of http. One advantage of this approach is that renewals can run on any machine, then you can install the certificate wherever it's required.


You are, of course, absolutely correct that an existing webserver running on port 80 will interfere with certbot's standalone authenticator's ability to operate. However, I don't believe that's what's happening here because typically the resulting error message indicates an inability to bind to port 80 whereas the current error message indicates an invalid response (incorrect content) being returned to the Let's Encrypt authentication server.

The commands themselves won't provide additional details. However, the standalone authenticator spins-up its own webserver on port 80 and --debug-challenges causes certbot to pause while keeping the temporary webserver operational, which will help you to debug your port 80 access.


Hi Griffin and webprofusion,

I managed to renew our certificate by running this command:
certbot certonly --manual --preferred-challenges=dns --email --server --agree-tos -d

I would like to confirm, that manual renewal requires us to update the TXT for the challenge? and we cannot do an automated renewal?

Thank you for your help!



It is possible to automate dns-01 challenges by using a dns plugin to manage the TXT records or by using acme-dns.


Yes, you will need to update the TXT record for every certificate renewal if using manual DNS but as @griffin mentioned there are many way to automate this, and automation is almost always the best solution.

I note from your http validation error that the request gets redirected to https, then your websphere application tries to respond but doesn't know how. So the standalone mode of certbot definitely didn't work but it may be that you are somehow performing the https redirect before it reaches your actual server (is there a proxying or load balancing service there). DNS validation is a great option anyway.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.