cool! doing...
done...
but no change in the behavior
I'd just remove the ifmodule
Would your sites work right without SSL enabled? No 
4 Likes
okay, trying...
done... now you can see the result (no change)
Put something similar in possible other VHosts but with slightly different values.
Then, try each combination you created
Put in the port 80 VHost for this domain and in any default server identified in the DUMP_VHOSTS command
You need to find where these requests are getting routed to
3 Likes
did the temp redirect thing too...
nothing different happens...
so, that v-host conf doesn't even gets read... right?
........................
now I'm reading this:
https://manpages.debian.org/bullseye/openssl/config.5ssl.en.html
That's what it looks like. Apache is not selecting that VHost to process the incoming request
Did you change any kind of network routing such that the incoming port 443 request gets changed to port 80 when sent to Apache? People with routers for example sometimes make this mistake in their NAT forwarding.
3 Likes
didn't touch the router, I don't think "my" server has one...
but I'm almost certain that a very banal mistake is the cause of this stupid situation...
thank you for your help so far!
I'll get back here tomorrow...
hopefully with a solution -- oh, I unplugged my monitor and didn't see ...
thanks!!
Peter
1 Like
You should reverse this if it didn't help. All your VHosts should be the same and normally these days the *:443 form is best. But, if you don't want to bother changing the others you should change this back to match them.
3 Likes
to my diary:
this is as far as got today / tonight:
openssl s_client -state:
/etc/apache2$ sudo openssl s_client -state
140285122123072:error:0200206F:system library:connect:Connection refused:../crypto/bio/b_sock2.c:110:
140285122123072:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111:
140285122123072:error:0200206F:system library:connect:Connection refused:../crypto/bio/b_sock2.c:110:
140285122123072:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111:
and more directly:
openssl s_client -connect bodygabor.hu:443
CONNECTED(00000003)
140491495269696:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:331:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 304 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
Yes, we knew that already. Osiris first pointed it out with a curl example
curl -I https://bodygabor.hu:443
curl: (35) error:0A00010B:SSL routines::wrong version number
curl -I http://bodygabor.hu:443
HTTP/1.1 200 OK
Date: Thu, 08 Jun 2023 21:54:18 GMT
Server: Apache
Content-Type: text/html; charset=UTF-8
3 Likes
hi Osiris,
I've only seen your post now...
thank you!
the problem, however, came without my active intervention
sounds bad, I know...
but I wasn't doing anything...
except deleting 3 certificates,
correcting the cert path in 2-3 vhosts so that apache wouldn't refuse restarting...
and reinstalling one certificate completely, after deleting... (but the problem already existed at this point)
clearly, it was the deleting after which the problem came...
certbot delete : number, number..
1 Like
I didn't realize Osiris was taking part in this thread!
cause I wrote too often...
but here is the latest (as suggested by schoen at this thread ):
sudo openssl s_client -connect bodygabor.hu -servername bodygabor.hu
139693832066368:error:0200206F:system library:connect:Connection refused:../crypto/bio/b_sock2.c:110:
139693832066368:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111:
connect:errno=111
The problem in that thread was a wrongly configured VHost not related to the one being tested. You wouldn't show us any others so we can't pursue that
Adding --servername to openssl s_client only changes things when the openssl version is fairly old. Recent versions set it by default. Or, if you want to do clever things by sending a servername different than the --connect name.
3 Likes
It's no that I keep info back for some undisclosed reason
I am simply against putting up on the "internet" my entire server's structure...
I am going to follow that method of enabling sites back one by one...
and report back
I have 2 IP addresses, and the other one is working perfectly...
if I had dumped here all my (not too many ) vhosts,
it would have been clear, and could have been tested....
sorry about that!
1 Like
SOLVED 
this was the door to the solution:
the comment by schoen:
(1) It’s possible that the problem is elsewhere in your Apache configuration (in terms of a separate misconfigured virtual host listening on port 443). It’s also possible that there’s some information in your Apache logs either at startup or at the time of an inbound connection that might help in diagnosing this.
here, in this thread:
my problem was that I didn't have error warnings
apache2 restart worked good
certbot renew --dry-run also worked good
nevertheless, I had some certbot renew errors...
just 1 or 2...
of which one was obviously a missing document root directory...
which I created...
anyway the core problem was
that I have 2 IP addresses...
and one vhost was configured at the nameservers using IP #2 (A record)
but in the vhost config it was pointed at IP #2
I changed the nameserver "A record"
and disabled a couple of vhosts...
and all of a sudden lots of errors came up!!!
apache2/error.log showed " Configuration Failed" messages...
and certbot renew --dry-run also showed ALL RED LINES.. full of errors...
and from these
I could figure what else was wrong beside one vhost being pointed to IP #2
whereas the A record at the nameserver pointed to IP #1
one other problem was...
a vhost config error...
I dropped the domain (a year ago!) "the-book.eu" ...
and started using "this-book.eu" instead...
and I changed the vhost file.. manually... not with a global "replace all" method...
and the server name remained the old one...
(a server alias with "this-book.eu" was added, probably by certbot, as a matter of fact, and the domain was usable, as far as I remember, but it wasn't really in use, cause my book is still in the making )
after I've corrected this,
all the red lines and errors were gone... (note: red lines during certbot renew were the same at each vhost/nameserver)
and the sites (which I haven't disabled by a2dissite) came back and work like normal...
THANK YOU VERY MUCH for your effort to help with this case...
I hope that the solution will be useful for someone in the future...
once again what schoen said:
(1) It’s possible that the problem is elsewhere in your Apache configuration (in terms of a separate misconfigured virtual host listening on port 443). It’s also possible that there’s some information in your Apache logs either at startup or at the time of an inbound connection that might help in diagnosing this.
1 Like
Glad you found the problem
It was night here the last 8 hours, so I couldn't reply earlier, but this might also have been found (might also not have) if you'd posted the entire DUMP_VHOSTS list As that would have shown the two IP addresses I believe with their associated vhosts. It probably would have triggered some raised eyebrows and thus further investigation a little bit sooner (although I was asleep anyway 
).
4 Likes
you are, I'm certain, absolutely right!
once again, sorry about that!
but when I see text / code from my server published I feel nausea
if you or MikeMcQ had seen the other IP address too, you would have suggested to check a domain running "on it"...
and there I would have found that one of them works... but one doesn't
either way, thank you big time,
to you and MikeMcQ too
I AM SO HAPPY now !
Certbot is such a clean cool thing, logical, beautiful, and also robust!
not to mention that it has changed the world wide web, for the better
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.