Setting up Vhost and SSL/TSL on my WEB server

Help
1

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. crt.sh | 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: tunefind.info

I ran this command: $ sudo certbot certificate

It produced this output: No certificates found.

My web server is (include version): Apache/2.4.62 (Rocky Linux 9.6)

The operating system my web server runs on is (include version): (Rocky Linux 9.6)

My hosting provider, if applicable, is:

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): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 3.1.0

This No certificates found. ERROR is due to something wrong with my Vhost setting. According to linkp and MikeMacQ, I separtely worte the vhost TAG file as “tnefind.info.conf” in the /etc/httpd/conf.d/ I may post it here, so that everyone look at possible my error.

= tunefind.info.conf =

<VirtualHost 192.168.1.6  110.3.33.130 >
     DocumentRoot "/var/www/html"
     ServerName   www.tunefind.info
</VirtualHost>


<VirtualHost *:80>
        ServerName www.tunefind.info
        Redirect  https://www.tunefind.info/
</VirtualHost>

Thanks for your help. I am completely a newbie for this SSL/TSL, https business. Thanks.

2

Why do you have this in your vhost conf?

<VirtualHost 192.168.1.6 110.3.33.130 >

Apologies if you have already explained that in a previous topic.

3

No, it isn't; that output from certbot means just what it says: you haven't obtained any certificates (or have deleted any certificates you have). To confirm, please post the output of sudo ls -lR /etc/letsencrypt.

If you were receiving help in another topic, it'd be much better to continue the discussion there than to create a new one.

4

Dear linkp, tunefind.info has the WEB_casting from condominium room in Hachioji, JAPAN. I set it up with a local ISP, Internet Service Provider, Kawasaki.internet (kinet.or.jp). ISP told me that TuneFind.info were able to WEB-cast from a condominium room, when I use appropriate Router and appropriate inter house LAN with IP assigment by “nmtui”. I did exactly ISP’s suggestion, and voila, WEB-casting started from a condominium room. Connection to the outside INTERNET world was done by the static Router IP (110.3.33.130), while in-house LAN the Router was configured to connect the particular WEB-casting computer by intra LAN IP (192.168.1.6). I found a similar WEB-casting circumstance in “Apache Documentation” as below.

<VirtualHost 192.168.1.1  172.20.30.40>
DocumentRoot "www/server1"
ServerName server.example.com
ServerAlias server

I copied the style.

5

Dear dannb35,

[root@svr1 etc]# cd letsencrypt
[root@svr1 letsencrypt]# ls
accounts cli.ini options-ssl-apache.conf renewal renewal-hooks
[root@svr1 letsencrypt]# ls -lR ./
./:
total 8
drwx------. 3 root root 42 Feb 11 2025 accounts
-rw-r--r--. 1 root root 152 Mar 27 2025 cli.ini
-rw-r--r--. 1 root root 1005 Feb 13 2025 options-ssl-apache.conf
drwxr-xr-x. 2 root root 6 Feb 11 2025 renewal
drwxr-xr-x. 5 root root 43 Feb 11 2025 renewal-hooks

./accounts:
total 0
drwx------. 3 root root 23 Feb 11 2025 acme-v02.api.letsencrypt.org

./accounts/acme-v02.api.letsencrypt.org:
total 0
drwx------. 3 root root 46 Feb 11 2025 directory

./accounts/acme-v02.api.letsencrypt.org/directory:
total 0
drwx------. 2 root root 64 Feb 11 2025 af2f258ed8c63ffbfbd85cde253533c8

./accounts/acme-v02.api.letsencrypt.org/directory/af2f258ed8c63ffbfbd85cde253533c8:
total 12
-rw-r--r--. 1 root root 126 Sep 27 13:49 meta.json
-r--------. 1 root root 1632 Feb 11 2025 private_key.json
-rw-r--r--. 1 root root 80 Sep 27 13:48 regr.json

./renewal:
total 0

./renewal-hooks:
total 0
drwxr-xr-x. 2 root root 6 Feb 11 2025 deploy
drwxr-xr-x. 2 root root 6 Feb 11 2025 post
drwxr-xr-x. 2 root root 6 Feb 11 2025 pre

./renewal-hooks/deploy:
total 0

./renewal-hooks/post:
total 0

./renewal-hooks/pre:
total 0
[root@svr1 letsencrypt]#

6

Dear danb35, the post was closed due to over one month no activities.

7

So, as I'd said, the reason certbot says No certificates found is because there are, in fact, no certificates. It has nothing to do with anything in your virtual host configuration, whatever issues there may be with it.

8

Dear danb35, then now what suppose to do from me. Should I run the command “#certbot –apache” again?

9

I'm not really a fan of Apache at all at this point, and would much prefer using Caddy (https://caddyserver.com/)--which, among other benefits, takes care of the certificate already. If you're unable or unwilling to use Caddy instead of Apache, look into using mod_md with Apache to automate the certificate process. Certbot should not be necessary at all with modern web server software.

10

I'm still an Apache fan, but I go for mod_md and not cerbot when obtaining certificates for Apache. When I did use certbot with Apache I always used webroot, because I don't want certbot touching my config files.

As for that vhost cofig, it seems unnecessary to specify the IPs, but, unless it is causing you problems, I'm not going to worry about it.

11

But, those two VirtualHost duplicate the same IP and port so, in this case, the second one is ignored. We can see that because HTTP requests are not redirected.

Worse, because the first VirtualHost does not specify a port it would (likely) take precedence from a VirtualHost setup just for HTTPS on port 443. Adding :80 to the public IP in the VirtualHost would probably be enough to avoid that problem. Or, rework the VirtualHost to be fully Name-based rather than IP-based.

Just for reference, this was what was posted earlier

12

Dear MikeMcQ and linkp, Thank you for various comment. I made it successfully installed SSL with the help with another community. I will just leave my experience in which I felt crucial. The first point was Certifications were issued or not. If not issued, they got to be issued. If not issued, there may have a problem at the step of Domain Verification or elsewhere. The second point was once Certificates were issued appropriately, installation of certificates aren’t a difficult step. Thus second point goes to VirtualHost configuration script. If VirtualHost configuration script (ssl,conf or a own brand new .conf file) are not at all read by Apache - httpd, then this situation is easily recognized by no ssl error log files at /logs/. Thus in this case, check it up with whether ssl error files are created by Apache - httpd (after restarting it) or not. In the case of no ssl error-logs, uncomment the following line at the end of httpd.conf file, ##IncludeOptional conf.d/*.conf (line # approximately 358). That enabled All .conf files are being read by Apache-httpd. The third point is, carefully read any possible additional error message from Apache - httpd. That’s all. After these improvements, I successfully installed VirtualHost with port 443.

13

I know you've solve the problem, but others here didn't give straight answers, I thought I'd try in case others have similar issues getting started and find this thread.

That's because you hadn't created any yet. I haven't created a new certificates in years, but I used something like the following:

certbot certonly -c /path/to/cli.ini --webroot --webroot-path /path/to/your/website/tunefind.info/ -d tunefind.info

That creates the certificate only ("certonly"), it doesn't change your config files. The cli.ini doesn't need much, mine only contains:

rsa-key-size = 4096
email = mkido@tunefind.info
agree-tos = True

I changed my email address, of course. And I chose the rsa key size in 2016. I should update it!

Anyway, that's how you get your certificate.

I started with an Apache configuration like this:

<VirtualHost *:80>
ServerName tunefind.info
DocumentRoot /path/to/www/tunefind
</VirtualHost>

That will allow cerbot to use webroot to create the certificate. Once you have the certificate, you can get Apache to use the certificate by changing the config to:

<VirtualHost *:80>
ServerName tunefind.info
Redirect / https://tunefind.info/
</VirtualHost>

<VirtualHost *:443>
DocumentRoot /path/to/www/tunefind
ServerName tunefind.info
SSLEngine on
SSLCertificateFile "/path/to/letsencrypt/live/tunefind.info/fullchain.pem"
SSLCertificateKeyFile "/path/to/letsencrypt/live/tunefind.info/privkey.pem"
</VirtualHost>

I hope this helps someone who gets stuck at the beginning!

14

Appreciate the input. :slightly_smiling_face: A few thoughts:

Not necessarily true because:

Specifying cli.ini is non-standard practice and using certonly rather than run with some type of installer (e.g. -i apache) is usually indicative of a manual or broken process and therefore not advisable since a webserver like Apache needs to be restarted to pick up new certificates.

A 4096-bit key size is excessive for most leaf certificates. Let's encrypt no longer stores email addresses for registration.

Not if you're using good practice.

You should be using the Apache installer as specified above and let certbot manage the Apache changes rather than managing them yourself.

Again, appreciate the input, but joining a solved topic over a week late then adding outdated and/or not-good-practice advice isn't especially helpful.

15

I definitely agree with this one. However...

I prefer certonly and my own hooks. I have no interest in letting certbot touch my config files.

On the contrary, if you are still using RSA keys, this should be your default minimum, and only ever be reduced for use in busted apps that cannot handle keys of this reasonable minimum size.

16

Yeah, certonly is also my preference.

Not sure why you would use 4096 bit keys when Let's Encrypt's RSA intermediate certs use 2048 bit keys. I can't think of any added security benefit; if someone can crack 2048 bit keys then they'll just target the intermediates.

17

What threat do think that presents to the traffic protected by the 4096 bit RSA? The intermediate isn't used to encrypt the traffic. It just vouches for the leaf certificate.

18

The intermediate isn't used to encrypt the traffic.

The leaf certificate isn't used for this either, ideally. With TLS1.2/1.3 cipher suites you have forward secrecy. I suppose there is a benefit to 4096 bit RSA keys if you have to support cipher suites that don't have this property. I hadn't considered that.

19

I have been preferring EC certs for a while now, so it's mostly academic. However, I do keep a couple of RSA around for legacy infrastructure and clients, including some internal-only that can only handle 2048 bit RSA.

20

You're not the average bear though :wink: and using installation tools built for the webserver is IMO usually advisable for the average bear, especially considering that what @DarkSteve was suggesting made no mention of any means of automated webserver reloading, hooks or otherwise.