I can generate certificates fine, but the root certificate is wrong.
Can you will specific example of how [quote=“OMYD_command, post:1, topic:36295”]
the root certificate is wrong
[And this issue seems unrelated to the topic: How to reset the server name in the certificate?]
maybe you could provide answers to the default help issue questions:
Please fill out the fields below so we can help you better.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
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’m using a control panel to manage my site (no, or provide the name and version of the control panel):
I believe you are referring to the commonName in the certificate, which is sometimes exposed as the primary domain name in browser certificate UIs. A “root certificate” is a certificate maintained by organizations like Let’s Encrypt and only used to sign other certificates.
The commonName becomes more irrelevant with each passing day (Chrome is going to ignore it soon) so it really doesn’t hurt anything if it’s not your primary domain.
If you really want to change it anyway, you must rerun certbot with
--force-renew, and specify all the domains again making sure to place the domain you want for the commonName first in the list.
Would removing let’s encrypt fully and reinstalling it fix this too?
I'm not sure what application that is. It is very weird that it lists only one Subject Alternative Name when there could be a hundred of them, all of them valid hosts for the certificate. If you can open the certificate file in Windows' built-in certificate viewer, you should be able to see all the Subject Alternative Names for your certificate on the Details tab.
Sure, but either way you do it you must remember to list the domain you want as the commonName first before your other domains.
Note that this way certbot will have to validate all of your domains over again, while a force renewal could use any unexpired approved validations.
It’s filezilla ftp. Thanks, I will mull this over.
That name resolves to that IP.
The only issue of immediate concern is that cert expired yesterday: https://crt.sh/?id=105431385
You can also run this from a Windows Command Prompt to connect to the server and list the Subject Alternative Names for what’s live on the server:
openssl s_client -starttls ftp -connect yourdomain.com:21 | openssl x509 -noout -text | findstr DNS:
If you don’t have openssl installed on your computer already for use with your Let’s Encrypt client you can download it here.
If assemblerserver.com is the real problematic certificate, I can see it doesn’t have any other domains listed as the Subject Alternative Name though. The primary domain name is the only name for that one. So your certificate is just wrong.
If that’s the case, you can issue a new certificate with the right domain name or add the domain name to the existing certificate, whichever you prefer.
It can take 24 hours for certificates to appear on crt.sh, so they could have already renewed it…
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.