Creating certificate validation failure

I’m trying to set up an SSL certificate for a staging website that resides on the domain.

I first attempted to create the certificate using the “sudo certbot --apache” command but this returns the “failed authorization procedure” (http-01) error.

After doing some extensive reading I have followed the common advice of creating the “.well-known/acme-challenge/” directories (with 755 permissions in the webroot) and placed a test file to see if it is available in a browser. This ( still returns a 404 and I’m unsure how to address the problem.

After that I tried to use the “sudo certbot certonly --webroot -w /var/www/html” command. This produces the same issue.

I’ve tried various permutations of the commands and from what I understand things are set up correctly (which clearly isn’t the case!). And now when I try to create the certificate again I encounter the rate limit error: “There were too many requests of a given type :: Error creating new order :: too many failed authorizations recently: see

So my questions are:

  1. Is this limit 24 hours? I assume there isn’t any way of doing “dummy test” to avoid the limit or to stop the problem reoccurring if I still cannot fix during my testing?
  2. How can I ensure access is possible to the /.well-known/acme-challenge directory (to fix the 404 issue)?
  3. Is there any other Apache configuration settings that I should double check?

I will do what I can to provide any terminal responses where possible, but with the rate limit, I’m somewhat hand-tied at the moment. But I have the letsencrypt logs if that helps?

Just for some background… this is a DigitalOcean droplet that was created by duplicating the production droplet (running Apache on Ubuntu 16.04). After that, I just amended the ServerName in the apache config to reflect the correct IP address.

:wave: Hi @sheixt, welcome to the community forum.

This is a one hour rate limit:

There is a Failed Validation limit of 5 failures per account, per hostname, per hour.

I recommend you try to diagnose your problems using the staging environment. It issues certificates that are not trusted by browsers but has much higher rate limits. The --staging flag of Certbot will let you use staging.

Can you share your full Apache configuration? I suspect the answer involves understanding the existing config.

Sharing those in a Gist or in the thread in triple backticks would be helpful. Thanks!

@cpu thanks for the feedback, really appreciate your time. :man_superhero:

Oh great, I thought I was going to be locked out all day!

Ah didn’t know that was an option, I will do whilst fixing this issue!

Sure, it’s here in a gist:

No worries, I created another Gist and tried to pick out a set of relevant logs from today:

If it’s not already apparent, I’m rather new to linux server configuration… so feel free to treat me like a complete fool :crazy_face:

1 Like

Not a problem :slight_smile: The forum is happy to help!

Thanks! One thing I notice is that the Certbot apache plugin is flagging an error in the Apache config file:

AH00526: Syntax error on line 224 of /etc/apache2/apache2.conf:
ServerAlias only used in <VirtualHost>

2019-06-11 12:28:40,416:DEBUG:certbot.plugins.disco:Misconfigured PluginEntryPoint#apache: Error while running apache2ctl configtest.
Action 'configtest' failed.

line 224 in the Apache config you shared above is blank, but line 225 has a ServerName:


My Apache config-fu is very rusty, but I think based on the ServerName docs it’s allowed to appear in a server config block outside of a virtual host. The error also specifically calls out a ServerAlias directive, not a ServerName so I think that’s perhaps a red herring.

Do you have any additional site configs under /etc/apache2/sites-enabled/ that you can share? I don’t see any VirtualHost or ServerAlias directives in the config you shared and I suspect they’re broken out into separate .conf files in /etc/apache2/sites-enabled.

@JuergenAuer Have you run into this case before? I might be in over my head debugging Apache configuration woes :laughing:

1 Like

I wouldn’t place a ServerName in that basic configuration file.

But that

ServerName Directive
Description:	Hostname and port that the server uses to identify itself
Syntax:	ServerName [scheme://]domain-name|ip-address[:port]
Context:	server config, virtual host
Status:	Core
Module:	core

says it’s possible.

Agreed about the ServerName directive, sorry I was specifically wondering if you’ve seen this error case:

ServerAlias only used in VirtualHost

1 Like

I think that was a temporary issue as I added the ServerAlias as the domain until I noticed the config error and just removed it, leaving the ServerName.

Solved it!
There were two additional configs under /etc/apache2/sites-enabled/. After looking through these, there were additional ServerName settings which reference the old domain! So on replaccing, those with the correct domain name everything works fine!

Thanks for your help @cpu for pointing me in the right direction. Much appreciated!


Hi @sheixt

thanks, good to know.

1 Like

Thanks for your insight @JuergenAuer.

Out of interest, where would you recommend maintaining the ServerName and ServerAlias directives? Just so I can conform to best-practice going forward…

1 Like

Glad to hear it! Thanks for reporting back!

1 Like

I would use these directives in vHost parts.

There are sometimes buggy configurations, the same port and more then one vHost with the same domain name as ServerName or Alias. Or more then one ServerName in one vHost.