Too many invalid authorizations recently

Could you post the log file from /var/log/letsencrypt and also your Apache configuration files from /etc/apache2?

yes this is the files
httpd.conf.txt (34.0 KB)
letsencrypt.log.txt (16.4 KB)

@bmw, could you please take a look at this?

1 Like

@dicn1978, if you run:

yum install mod_ssl

does it install any packages? If so, try running letsencrypt-auto again afterwards and see if it fixes the problem.

Hello I could install and run the certificate
but I have another question:
If I add another virtual host on the same server for example would have to install another certificate or with the same you can have all the sites you need?
thanks for your help

Hello I could install and run the certificate
but I have another question:
If I add another virtual host on the same server for example would have to install another certificate or with the same you can have all the sites you need?
thanks for your help

You can have up to 100 names in a single certificate. This is because some browsers have issues with lots of names in certificates.

You can request as many certificates as you need within the rate limits of the service.

Putting all the names on a single certificate or using multiple certificates is up to you. You can configure it to work with how you want to manage things.

In this case you need to copy the files. Does the other virtual host route or re-specify the path of the first certificate I install?
for example
<VirtualHost *:443>
SSLEngine on
SSLProtocol all -SSLv2
#SSLCertificateFile /etc/letsencrypt/live/
#SSLCertificateKeyFile /etc/letsencrypt/live/
SSLCertificateFile /etc/letsencrypt/live/
SSLCertificateKeyFile /etc/letsencrypt/live/
SetEnvIf User-Agent “.MSIE.
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
#SSLCertificateChainFile /etc/letsencrypt/live/
SSLCertificateChainFile /etc/letsencrypt/live/

    DocumentRoot /var/www/

    <Directory />
        AllowOverride All

    <Directory /var/www/>
        AllowOverride All

    ErrorLog /var/log/httpd/

Apache has some kind of internal table of mappings between host names and virtual hosts, and so when a browser connects and requests a particular hostname, Apache looks it up in that internal table and figures out which virtual host to use. I believe this table is built primarily on the basis of the ServerName and ServerAlias directives, not by parsing the contents of the certificates. If my interpretation is right, you have full control over which certificate will be used when a particular name is requested because you can pick which virtual host will correspond to that name.

I’m not sure how the lookups are done internally, but Apache uses the ServerName and ServerAlias directives as the authoritative source for what sites to serve for those names, not the certificates.

The major exception is that non-matching names load up the default site for that port. The defaults are picked as the first site definition in the configuration. The main config, httpd.conf, is loaded first and includes are loaded in alphabetical order and read top-down in order of their inclusion in the primary config file.

1 Like

thanks you and your team for your help

In the case of Linux centos you have a guide or tutorial that explains how to make the certificate automatically renew

There are tons of guides available for this, but the typical method is something along the lines of a cron job running twice daily with a certbot renew command.

E.g. certbot-auto renew

Edit: Fixed my own misunderstandings!

Please don’t specify options like --apache with certbot-auto renew! That could mess up people’s setups.

When you specify an authenticator like that, it gets applied for the renewal of all certificates that are renewed, even if they originally used a different authenticator. Remember that certbot-auto renew looks at every existing certificate and attempts to renew it when it’s near expiry. But people could have used --nginx or --webroot or something, which means they should not be using --apache for renewal.

1 Like

What I particularly want to say about this is that certbot renew is meant to be totally different from certbot certonly.

When you get the certificate (with certonly or the implicit or explicit run), you need to tell Certbot how to get and optionally install your certificate, and what the certificate should contain. When you run certbot renew, it runs unattended and acts on all of your certificates; you should normally not tell it anything about how to get certificates or what they should contain, because it will automatically use the renewal parameters that were saved when the certificate was obtained.

I use this command /opt/letsencrypt/./letsencrypt-auto renew
is this right???
i make a script in crontab with this order
thanks for your help :slight_smile:

. in Unix means the current directory, so /opt/letsencrypt/./letsencrypt-auto is the same file and location as /opt/letsencrypt/letsencrypt-auto (or /opt/letsencrypt/./././././././letsencrypt-auto).

By the way, letsencrypt-auto was renamed to certbot-auto more than a year ago. Did you find a tutorial using the old name? It still works fine, but we're trying to encourage people who write documentation to switch over to the current name to reduce confusion (since some people mistakenly expect that there's an important difference of some sort between letsencrypt and certbot).

That name was given to me by a friend who uses the certificates, is there a problem if I use it or is it just a question of names?

It's completely valid, but it implicitly suggests a limited understanding of Unix to me.

Edit: Sorry, I guess you were asking about letsencrypt vs. certbot rather than about the ., but my answer related to the .

I think the . suggests a limited understanding of Unix while the letsencrypt vs. certbot is just about our effort to get everyone to refer to the program as certbot to try to avoid future confusion.


Then write me the correct form of the order so that I can put it in crontab script

/opt/letsencrypt/certbot-auto renew