From: "Steven Levine" Received: from [192.168.100.201] (HELO mail.2rosenthals.com) by 2rosenthals.com (CommuniGate Pro SMTP 5.4.10) with ESMTP id 10596452 for ecs-isp@2rosenthals.com; Tue, 13 Aug 2024 23:08:19 -0400 Received: from secmgr-va.2rosenthals.com ([50.73.8.217]:56691 helo=mail2.2rosenthals.com) by mail.2rosenthals.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1se4Ms-000000003zi-1cud for ecs-isp@2rosenthals.com; Tue, 13 Aug 2024 23:08:10 -0400 Received: from mta-201b.earthlink-vadesecure.net ([51.81.229.181]:44827 helo=mta-201a.earthlink-vadesecure.net) by mail2.2rosenthals.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.97.1) (envelope-from ) id 1se4Mj-000000007br-1N1f for ecs-isp@2rosenthals.com; Tue, 13 Aug 2024 23:08:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; bh=xAb5z8s2JQO2DReqSak+eN0cO8qoWe+eSZIo5l O4bK4=; c=relaxed/relaxed; d=earthlink.net; h=from:reply-to:subject: date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to: references:list-id:list-help:list-unsubscribe:list-unsubscribe-post: list-subscribe:list-post:list-owner:list-archive; q=dns/txt; s=dk12062016; t=1723604880; x=1724209680; b=ZnfPSx+anpFqTyX8xs2hFWTkBx5 FNVD/T4EmhcAQLHoycimwM6VZnE8rOpKswHjCpjRfj1BxmeO488+6/PDQ0SWZr92rHSMhso k5wNF+A8NM7OeU5Ij6lHiaFjuqrrK0sHPOCbff/xGEuATSgUeSC8njM9jALJYlLojrlD8gL c0QPjZTORUxXfHaww0fBt6FjviOlKLL4H9PYPTLyHF+yCaEgABbjrpUhLN1Q1BkZzXrF7zS /BzE7o1mYfhjGU/+XBCBukO9wKDsrkAiDt5FD9G2a2dFuz31mZlFUD/0s8Lk53tYo4p1b8c qGgYJjT4Z7pBYzhHi5IuptiKY/Q+FnQ== Received: from slamain ([172.56.240.198]) by vsel2nmtao01p.internal.vadesecure.com with ngmta id f8875901-17eb7981962f3050; Wed, 14 Aug 2024 03:08:00 +0000 Message-ID: <66bc0161.22.mr2ice.fgrirsq@earthlink.net> Date: Tue, 13 Aug 2024 17:59:13 -0700 To: "eCS ISP Mailing List" Subject: https for scoug.com X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.24/60 Hi, I decided to enable scoug.com for https using Let's Encrypt certificates and ran into an unrelated issue that I don't fully understand. This is not a completely new setup. I had https working with a self-signed certificate a while back but it's been disabled until now so it's hard to know what might have changed in the interim. So I re-enabled SSL and switched over to a Let's Encrypt certificate and the clients were not able of fetch the certificate. Both sslchecker and openssl's s_client failed. The failure mode persisted even if I switched back the the self-signed certificate. The iptrace logs reported: HTTP/1.1 400 Bad Request Date: Tue, 13 Aug 2024 23:19:28 GMT Server: Apache Content-Length: 226 Connection: close Content-Type: text/html; charset=iso-8859-1 400 Bad Request

Bad Request

Your browser sent a request that this server could not understand.

which implied to me that somehow the request was not getting routed to the SSL enabled VirtualHost. After much grumbling and complaining, the fix turned out to be modifying the Listen statement. The server has two interfaces: > ifconfig lan1 lan1: flags=b863 metric 1 inet 192.168.1.15 netmask 0xffffff00 broadcast 192.168.1.255 and we were listening with Listen 64.60.60.121:80 Listen 80 Listen 443 along with Unless I missed something in the docs, I would expect that traffic coming in on 64.60.60.121:443 would get routed to the 64.60.60.121:443 VirtualHost, but this did not happen. The fix was to use Listen 64.60.60.121:80 Listen 80 Listen 64.60.60.121:443 The fully qualified listen matched what the VirtualHost processing code wanted to see and we got the expected results. What I don't yet understand is why the explict listen was required. There are two inferfaces, but the request clearly arrived via the lan1 interface Any ideas? Thanks, Steven -- ---------------------------------------------------------------------- "Steven Levine" Warp/DIY/BlueLion etc. www.scoug.com www.arcanoae.com www.warpcave.com ----------------------------------------------------------------------