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:vcstulsa.org
I ran this command:tried to reissue cert in DirectAdmin
It produced this output: Weekly Rate limit of 200 for 'vcstulsa.org' has been reached. The problem appears to be that it has been trying to renew the cert but the cn is shoing the hostname of the server and not the name for the account of the website.
My web server is (include version):Litespeed v-Enterpise 6.3
The operating system my web server runs on is (include version):Almalinux
My hosting provider, if applicable, is:KnownHost
I can login to a root shell on my machine (yes or no, or I don't know):yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):yes, DirectAdmin
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
Exactly--you've created five identical certs within the past week. Why don't you use one of them?
I don't know what configuration problem on your end is causing this, but it has nothing to do with the CN on your certificate. I don't know what "200 limit" you're referring to; the limit is five identical certs, and 50 certs/domain, per week--you've hit the first of those.
Unfortunately, some technologies (inappropriately) use the (long-obsolete) CN field in a certificate for identification/verification purposes. Unless you're affected by this erroneous behavior, the CN should just be ignored. I believe there's a good chance that Let's Encrypt (and probably other CAs in the near future) will omit the CN field entirely from issued certificates.
Ok, For some reason my certificate does not work. The date seems to be valid but the cert is not so I figured it was the cn issue since all my other certs the cn is the same as the website domain and not the host servers hostname. Are you thinking that becuase I do not have a cname for ftp, pop, webmaile etc that it is failing to create the cert and that once the rate limit is lifted (which shows 5:31 tomorrrow morning) then I can make sure I only select the main domain and the cert should issue correctly?
Are you alright with using an ECDSA key pair (rather than an RSA key pair)? Right now you're using an ECDSA key pair, which could cause problems depending upon your context.
I personally dont care which key pair is used. I use DirectAdmin on my webserver. In the Admin SSL section it shows all the websites and their certs and the status. If I click on a working account it shows the cert and the cn=correctdomainname.com. On this account it doesn't. I seems that maybe it tried to renew a cert and is failing because it can't find those cnames and doesnt issue the cert, even for the valid cnames.
I just threw up a positive ssl cert because the client needed the site up so it is working now. However, before I did that if you went to the site and inspected the cert the common name would show the servers host name. So it appears that there was not a cert at all on that account, it kept trying to renew all the cnames and since several of them didnt work it didnt issue and then never got a valid cert for the cnames that were there.
now that I have installed a paid postivessl cert on the site if I go to DirectAdmin - AdminSSL - and click on the green info icon it does show the correct cn=vcstulsa.org where before it was showing cn=serverhostname
No cert issued by Let's Encrypt is going to have this. Again, no modern application cares what the cn field says (so whatever your problem is, it's very unlikely it's this), but this suggests it's some kind of default, self-signed cert, and that certainly could cause problems.
I concur with @danb35's conclusion. I think you had a default (likely self-signed/"snakeoil") certificate with the hostname as the CN. My previous observations still hold.
For any active host/domain name that needs to be secured by the platform, but doesn't have a valid certificate installed, a default/self-signed/snakeoil certificate will usually be generated and installed simply so that HTTPS will function rather than crashing. That means "insecurely function", not "securely function". You were observing a symptom of the actual problem in this scenario.
Ok, that makes sense. When this cert is about to expire I will go in and make sure it is set to only generate a certificate for valid cnames and see if that does the trick. I think you guys are right and I think that if it finds invalid cnames it doesnt end up issuing any of them. I may set up a sample domain and test that theory. It must be right because it tried to get a cert over 200 times and still the cert area showed empty so it obviously was not getting anything. Also, if I set it to a wildcard cert it would probably work as well.
I am not sure. This was a site i moved from a cpanel server to DirectAdmin server so I think what must have happened was the cert was fine for a while until the cpanel one expired and then when it tried to renew it tried to do all those cnames, which I don't have and didn't specify, and so it failed and kept trying and I didn't get the notification because for some reason the email didnt send and I am not a bit time providor so I only check on the server if there is a problem. Have to do my day job, that is kind of a side job
