Hello,
I’m using CentOS 8 with Apache. This server hosting a WordPress website and I want to prepare it for HTTPS.
I have some questions and I’m thankful if people here, answer to them:
1- Linux by default using “localhost.localdomain”, is it an important name and must I change it to my domain name? I asked it because of “Mismatch” error like below:
If I want to change it then for a web site with the name “example-test.net” and “192.168.1.2” IP address, what is the content of “/etc/hostname” and “/etc/hosts” files? Is below configuration OK?
The /etc/hosts is an operating system file that translate hostnames or domain names to IP addresses. This is useful for testing websites changes or the SSL setup before taking a website publicly live.
The /etc/hostname contains name of the machine, as known to applications that run locally.
I think these are important files. Thus my “hosts” file must the domain name with its suffix? “example-test.net” not “example-test” ?
2- Certbot need “localhost.crt” and “localhost.key” files, If “/etc/pki/tls/private/localhost.key” and
“/etc/ssl/certs/localhost.crt” files deleted then how can I regenerate them? Is below command OK?
Please notice the "No SNI" remark at the table header. You're seeing some placeholder certificate, which is sent by default if a TLS request without SNI has been used. All modern browsers support SNI.
If you just have a single site operating on your webserver, you could choose to remove the default HTTPS virtualhost with this fake certificate and make your sites virtualhost the default. That way, even non-SNI clients would show the correct certificate.
No no no no no. As already implied on your previous topics (of which this is again..... a new one.....), the hostname and hosts files have absolutely nothing to do with TLS and their certificates!
There're not.
Doesn't matter.
No, it doesn't. Your webserver or other services might, but not certbot.
If they are not important then why Google said "This is useful for testing websites changes or the SSL setup before taking a website publicly live." and why when I changed the files then my site take down?
I guess you wrong. Test it yourself. When these files not exist then "certbot --apache" show you an error. These files made by Apache. I tested it. When Apache started then it create these files and the "CN" field of one of them is equal to the name that is in "hostname" file.
Why Certbot ask a question like below if they are same?
I don't know where that quote came from, but you can indeed use the hosts file to connect to IP addresses other than what the DNS server says, so you can connect to a local development setup/testing server in stead of the production server. For the TLS configuration it doesn't matter. Please read and learn what those files actually do and how it doesn't directly relate to TLS.
That's because Apache indeed can require those files. And certbot uses Apache when the apache plugin is used. Certbot doesn't use thosse files directly.
If you use certbot --apache, Certbot will create a new, independent virtual host, which will be configured to point to Certbot's own differently-named files. On the other hand, if you use certbot certonly, then you have to edit the Apache configuration yourself. In that case, if you wanted to use the existing default HTTPS virtual host for some reason, you would need to change either what that existing virtual host expects the certificate files to be called, or what these files are called on disk.
It will probably be easier to use certbot --apache and let Certbot take care of it for you. In that case, the eventually-used new certificate files will not have the same names as the Apache defaults.
These names are different, and the best answer is usually 1,2 to select both. The idea is that if a user types in either https://mydomain.net/ or https://www.mydomain.net/ in a browser, you would like it to work properly. For that, you want to have both names listed on the certificate, except for Google Chrome, because Google decided to automatically treat the www subdomain as the same domain for certificate matching purposes, even though that's not really what the standards say to do.
Both of these relate only to how the machine sees and refers to itself, and so they're independent of how either the Let's Encrypt certificate authority or a visitor to your web site would see or refer to your machine. They affect the behavior of commands that you yourself run on your server, but not the behavior of a visitor's web browser when accessing your site over the Internet.
Thank you for your reply.
Thus the contents of my “/etc/hosts” and “/etc/hostname” can anything and it is not matter to my website certificate? Certbot just see the value of “ServerName” in Apache or Virtual Host configuration and…
Correct. /etc/hostname isn't used at all by certbot/TLS and /etc/hosts is used by your operating system to bypass DNS requests to your DNS server or let your client connect to "fake" hostnames which aren't in the DNS system. And isn't used by certbot at all.
Correct. Or to be more exact: the apache plugin of certbot. There is also a nginx plugin, which can read the nginx configuration file(s). Without those two plugins, you'd need to enter the FQDNs you want on the command line with the -d option.
Thank you so much for your reply.
The odd part is that I can’t understand why my server take down when I manipulated these files
I reverts everything to “localhost.localdomain”.
My URL is under limit rule and I want to continue this thread when limitation finished and I hope this thread not closed.
About certificates, can a SSL provider take down a website by its certificate? For example, Let’s Encrypt take down a website that using its certificate.
I'm not sure what happens or why it should happen. Just keep it in the situation where your server is working.
Please use the staging environment when testing. There is absolutely no need to run into rate limits under normal circumstances.
"Down", as in, "nobody can connect to the site any longer, even HTTP"? Then no. But CA's can revoke a certificate, which would invalidate the HTTPS site if a revoked certificate is in use.
With just one line of data, we can't say definitive. While @griffin is correct, based upon the latest cert, the 10th the limit will most certainly be lift, but could be lifted sooner. But no way to know with so little info.
Also, I'm willing to suggest a global Community wide rule that people looking for answers where a lack of domain name is very irritating and where helping is very much hampered, the topic shall be closed with a generic warning if one will not give the domain name if requested.
