Does it work with apachectl ? or apache2ctl ?
should be this, please show again
The two commands :
root@1150-SRV:~# apachectl configtest
Syntax OK
root@1150-SRV:~# apache2ctl configtest
Syntax OK
How odd ! I've always used apache2ctl
And, what about this? You know we are unpaid volunteers here offering our personal time for free. We all have things we could be doing instead of asking the same questions over and over.
Sorry...
root@1150-SRV:~# apache2ctl -t -D DUMP_VHOSTS
VirtualHost configuration:
*:80 msrv.brusses.fr (/etc/apache2/sites-enabled/msrv.brusses.fr.conf:1)
*:443 msrv.brusses.fr (/etc/apache2/sites-enabled/msrv.brusses.fr.conf:26)
And, what is the contents of this exact file. You showed some VirtualHost config earlier but I was not sure what file that was. thanks
Here it is :
Modified, as you told me on the SSLCertificateChainFile directive
<VirtualHost *:80>
ServerName msrv.brusses.fr
ServerAlias www.msrv.brusses.fr
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html/owncloud
Redirect permanent / https://www.msrv.brusses.fr/
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
<Directory /var/www/>
Options FollowSymLinks
AllowOverride Limit Options FileInfo
DirectoryIndex index.php
Require all granted
AllowOverride all
</Directory>
<VirtualHost *:443>
ServerName msrv.brusses.fr
ServerAlias www.msrv.brusses.fr
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html/owncloud
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/msrv.brusses.fr/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/msrv.brusses.fr/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/msrv.brusses.fr/chain.pem
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
I guess I don't understand the problem.
That Apache config only shows one VirtualHost using a file from the letsencrypt folders
But, if I look at the domain from the public internet it has a DigiCert certificate
You either have different IP addresses for different Apache servers. Or, are routing the requests to the wrong Apache. Or, I just don't understand what you are trying to do. Sorry
You're right.
It's better to go back, generate a new certificate and so on.
My host has just told me on the phone that, from his site, the ping returns an ipv4 on the main domain name. But not at my place ...
Anyway, I give the return ![]()
Thanks a lot.
The first says nothing is listening to port 80.
The second says Apache is listening to port 80.
How is that possible?
You don't need any more certs. In fact, I was a little surprised certbot only showed the one. I show just a few of the recent certs you got below. The logs are often a little behind so be careful not to get rate limited (you only get 5 per week with same names)
You can check the IP you are on many ways but this is one way
curl -4 https://ifconfig.io
curl -6 https://ifconfig.io
Some of your recent certs
@rg305 :
Probably because of the double virtual host.
If I disable listening on port 80 (which cerbot needs when generating the certificate), there's only 443 left.
Please explain what you mean.
Yes. I deleted the part of the vhost on port 80. A participant was surprised that Apache uses two vhosts: one on 80, the other on 443.
But it's getting worse. And nothing to do with this.
Look at all this ipv6!
<VirtualHost *:443>
ServerName msrv.brusses.fr
ServerAlias www.msrv.brusses.fr
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html/owncloud
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/msrv.brusses.fr/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/msrv.brusses.fr/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/msrv.brusses.fr/chain.pem
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
root@1150-SRV:~# lsof -i:443
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
apache2 904 root 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1872 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1873 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1876 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1877 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1880 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1882 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1885 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1889 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1890 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1891 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1892 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1894 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1896 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1897 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1898 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1899 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1900 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1901 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1905 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1906 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1907 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1908 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1909 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1910 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1911 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1913 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1914 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1915 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1916 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1917 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1918 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1919 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1920 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1921 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1922 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1923 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1924 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1925 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1926 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1927 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1928 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1929 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1930 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1931 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1932 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1933 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1934 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1936 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1937 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1938 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1939 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1940 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1942 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1948 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1949 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1950 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1951 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
apache2 1952 www-data 4u IPv6 21160 0t0 TCP *:https (LISTEN)
It's crazy...
I think all I have to do now is reassemble the server properly. And on another sub-domain.
Apache never did that to me!
And even after a
apache2ctl --enable-v4-mapped
then reboot, no better.
This is not an Apache forum.
That said, you might want to check something along the lines of ThreadsPerChild.
It's not; It's something in your configuration file that is starting all those listeners.
Also, for Apache, "TYPE IPv6" listeners actually also include listening on IPv4.
I think you misunderstood. It is very common to have VHosts for both ports. In fact, Let's Encrypt recommends a port 80 VHost so you can redirect to HTTPS
I understand.
So I'm putting back the vhost as advised by Letsencrypt.
With the two ports.
Hello everyone.
I started from a Clonezilla image. The server was in HTTP and working.
This morning, after switching to HTTPS with Certbot, the owncloud client connects normally to the subdomain URL. Not the public IP, but indeed
the subdomain URL.
Syntax used according to my tutorials :
certbot -d msrv.brusses.fr certonly --manual --preferred-challenge dns
Even under Tor, I can access the server login by typing its URL.
So, everything seems to be working.
I've just modified the sub-domain.
In the DNS, field 'A', I entered the public IP of the box. So, of the server.
Thank you all !!
But... what happened ?
only this question of IP ?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
