Hi Daniel, If we want to disable this Proxy setting in httpd - how will we do that ? I can see below logs in the file . If the SSL settings is all correct then I think we can try to disable the Proxy setting that you mentioned but I don't know how to do that.
[root@amdc2webl06 logs]# tail -f ssl_error_log [Tue Jan 07 02:50:38.254032 2020] [autoindex:error] [pid 23200] [client 10.19.79.68:53112] AH01276: Cannot serve directory /var/www/html/: No matching DirectoryIndex (index.html,index.php,index.php) found, and server-generated directory index forbidden by Options directive [Tue Jan 07 02:50:39.716018 2020] [autoindex:error] [pid 23199] [client 10.19.79.68:53788] AH01276: Cannot serve directory /var/www/html/: No matching DirectoryIndex (index.html,index.php,index.php) found, and server-generated directory index forbidden by Options directive [Tue Jan 07 02:50:39.932384 2020] [autoindex:error] [pid 23216] [client 10.19.79.68:53908] AH01276: Cannot serve directory /var/www/html/: No matching DirectoryIndex (index.html,index.php,index.php) found, and server-generated directory index forbidden by Options directive [Tue Jan 07 02:50:40.544248 2020] [autoindex:error] [pid 33866] [client 10.19.79.68:54156] AH01276: Cannot serve directory /var/www/html/: No matching DirectoryIndex (index.html,index.php,index.php) found, and server-generated directory index forbidden by Options directive [Tue Jan 07 07:59:13.246960 2020] [ssl:warn] [pid 5054] AH01909: RSA certificate configured for amdc2webl06.dmz.local:443 does NOT include an ID which matches the server name [Tue Jan 07 07:59:13.300537 2020] [ssl:warn] [pid 5054] AH01909: RSA certificate configured for amdc2webl06.dmz.local:443 does NOT include an ID which matches the server name [Tue Jan 07 08:01:39.423416 2020] [ssl:warn] [pid 5974] AH01909: RSA certificate configured for amdc2webl06.dmz.local:443 does NOT include an ID which matches the server name [Tue Jan 07 08:01:39.474833 2020] [ssl:warn] [pid 5974] AH01909: RSA certificate configured for amdc2webl06.dmz.local:443 does NOT include an ID which matches the server name [Tue Jan 07 08:02:33.125257 2020] [ssl:warn] [pid 6406] AH01909: RSA certificate configured for amdc2webl06.dmz.local:443 does NOT include an ID which matches the server name [Tue Jan 07 08:02:33.177513 2020] [ssl:warn] [pid 6406] AH01909: RSA certificate configured for amdc2webl06.dmz.local:443 does NOT include an ID which matches the server name ^C [root@amdc2webl06 logs]# tail -f error_log [Tue Jan 07 08:01:39.504771 2020] [core:notice] [pid 5974] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Tue Jan 07 08:02:32.013476 2020] [mpm_prefork:notice] [pid 5974] AH00170: caught SIGWINCH, shutting down gracefully [Tue Jan 07 08:02:33.119316 2020] [suexec:notice] [pid 6406] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Jan 07 08:02:33.125371 2020] [ssl:warn] [pid 6406] AH02292: Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366) [Tue Jan 07 08:02:33.151010 2020] [so:warn] [pid 6406] AH01574: module php7_module is already loaded, skipping [Tue Jan 07 08:02:33.151034 2020] [so:warn] [pid 6406] AH01574: module rewrite_module is already loaded, skipping [Tue Jan 07 08:02:33.171859 2020] [lbmethod_heartbeat:notice] [pid 6406] AH02282: No slotmem from mod_heartmonitor [Tue Jan 07 08:02:33.177681 2020] [ssl:warn] [pid 6406] AH02292: Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366) [Tue Jan 07 08:02:33.207983 2020] [mpm_prefork:notice] [pid 6406] AH00163: Apache/2.4.6 (SLES Expanded Support platform) OpenSSL/1.0.2k-fips PHP/7.3.11 configured -- resuming normal operations [Tue Jan 07 08:02:33.208026 2020] [core:notice] [pid 6406] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' ^C [root@amdc2webl06 logs]# Regards Sachin Kumar On Tue, Jan 7, 2020 at 5:33 PM Daniel Ferradal <[email protected]> wrote: > As I see it, even if it is IIS it is configured correctly and replying > otherwise you would not even reach the point of the 502 error which refers > to a backend to the server you are talking to is trying to contact > > What I would do is: > * Find out why something else seems to be replying > * Supposing it is an Azure thing impersonating Apache in its responses, > SSL seems correctly configured, so nothing else to do, so then those 502 > could be related to the fcgi backend "ProxyPassMatch ^/(.*\.php(/.*)?)$ > fcgi://127.0.0.1:9054/sites/amnetgroup.com/public_html/$1" you have > configured in apache rather than anything related to SSL. > > * But nonetheless Find out what that 502 is about. Try testing your apache > server with its local ips. > * Earlier Comments regarding clients not understanding or complaining > about wildcard certificates still stand. > > El mar., 7 ene. 2020 a las 12:54, Sac Isilia (< > [email protected]>) escribió: > >> Hi Daniel, >> >> Let me clarify the whole chain of events >> >> 1. We received a request to renew the SSL certificate that is set to >> expire on 23rd Jan 2020 >> 2. Post which we generated the CSR and sent the .csr file to the Digicert >> (RapidSSL) to issue us a wild card certificate with 2 years warranty. >> 3. They sent a PKCS#7 file to us that contained the certificate in .p7b >> extension and the other GLOBAL and ROOT CA certificate (bundle >> certificate). >> 4. We converted the .p7b to .crt with the command that I mentioned >> earlier. The new .crt contained not only the wildcard certificate but also >> the GLOBAL and ROOT CA certificate as well. We copied the wildcard >> certificate and replaced with the .crt file and the bundle certificate in >> the respective files. >> 5. The private key was also modified as well. >> 6. httpd service restarted. The service never reported any error. >> >> Now I am not sure why this IIS server is coming in the output. I ran this >> command on the server on which website (amnetgroup.com is hosted). The >> server on which website is hosted runs Linux and I ran the suggested >> commands from that server only. >> >> We received below certificates. The *.amnetgroup.com was copied to >> amnetgroup.com.crt and RapidSSL was copied to bundle file and the private >> key. >> >> [image: image.png] >> >> Please let me know if I can clarify on something else that I am missing. >> >> Regards >> Sachin Kumar >> >> On Tue, Jan 7, 2020 at 3:57 PM Daniel Ferradal <[email protected]> >> wrote: >> >>> I have no clue about Azure, sorry. >>> >>> But I can tell the server that responds says it is not Apache, if that >>> is some kind of frontend (the IIS server that is replying), maybe that >>> one is acting as a client proxing to the apache you mentioned earlier, >>> that would explain the errors and confirm what I mentioned earlier. >>> >>> But before anything else, better clarify what really is going on. >>> >>> El mar., 7 ene. 2020 a las 11:18, Sac Isilia >>> (<[email protected]>) escribió: >>> > >>> > Hi Daniel, >>> > >>> > The server on which SSL certificate is installed runs RHEL but >>> recently the server was migrated to Azure two months ago. Is there need to >>> be done from Azure end as well? >>> > >>> > Regards >>> > Sachin Kumar >>> > >>> > On Tue, 7 Jan 2020, 15:44 Daniel Ferradal, <[email protected]> >>> wrote: >>> >> >>> >> I'm confused now. The server responding says it is a IIS server, not >>> Apache. >>> >> >>> >> "Server: Microsoft-IIS/10.0" >>> >> >>> >> And the 502 is while it is trying to proxy somewhere, so... >>> >> >>> >> El mar., 7 ene. 2020 a las 6:11, Sac Isilia >>> >> (<[email protected]>) escribió: >>> >> > >>> >> > Hi Daniel/Team, >>> >> > >>> >> > I ran the command as you suggested - curl -vI >>> https://www.amnetgroup.com and it got below message. >>> >> > >>> >> > [root@amdc2webl06 cert]# curl -vI https://www.amnetgroup.com >>> >> > * About to connect() to www.amnetgroup.com port 443 (#0) >>> >> > * Trying 52.167.221.189... >>> >> > * Connected to www.amnetgroup.com (52.167.221.189) port 443 (#0) >>> >> > * Initializing NSS with certpath: sql:/etc/pki/nssdb >>> >> > * CAfile: /etc/pki/tls/certs/ca-bundle.crt >>> >> > CApath: none >>> >> > * Server certificate: >>> >> > * subject: CN=*.amnetgroup.com >>> >> > * start date: Jan 23 00:00:00 2019 GMT >>> >> > * expire date: Jan 23 12:00:00 2020 GMT >>> >> > * common name: *.amnetgroup.com >>> >> > * issuer: CN=RapidSSL RSA CA 2018,OU=www.digicert.com,O=DigiCert >>> Inc,C=US >>> >> > * NSS error -8179 (SEC_ERROR_UNKNOWN_ISSUER) >>> >> > * Peer's Certificate issuer is not recognized. >>> >> > * Closing connection 0 >>> >> > curl: (60) Peer's Certificate issuer is not recognized. >>> >> > More details here: http://curl.haxx.se/docs/sslcerts.html >>> >> > >>> >> > curl performs SSL certificate verification by default, using a >>> "bundle" >>> >> > of Certificate Authority (CA) public keys (CA certs). If the >>> default >>> >> > bundle file isn't adequate, you can specify an alternate file >>> >> > using the --cacert option. >>> >> > If this HTTPS server uses a certificate signed by a CA represented >>> in >>> >> > the bundle, the certificate verification probably failed due to a >>> >> > problem with the certificate (it might be expired, or the name >>> might >>> >> > not match the domain name in the URL). >>> >> > If you'd like to turn off curl's verification of the certificate, >>> use >>> >> > the -k (or --insecure) option. >>> >> > >>> >> > After that I updated the file /etc/pki/tls/certs/ca-bundle.crt >>> with the certificate details issued to us and then I ran the command again >>> and it showed the below message. >>> >> > >>> >> > [root@amdc2webl06 cert]# curl -vI https://www.amnetgroup.com >>> >> > * About to connect() to www.amnetgroup.com port 443 (#0) >>> >> > * Trying 52.167.221.189... >>> >> > * Connected to www.amnetgroup.com (52.167.221.189) port 443 (#0) >>> >> > * Initializing NSS with certpath: sql:/etc/pki/nssdb >>> >> > * CAfile: /etc/pki/tls/certs/ca-bundle.crt >>> >> > CApath: none >>> >> > * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >>> >> > * Server certificate: >>> >> > * subject: CN=*.amnetgroup.com >>> >> > * start date: Jan 23 00:00:00 2019 GMT >>> >> > * expire date: Jan 23 12:00:00 2020 GMT >>> >> > * common name: *.amnetgroup.com >>> >> > * issuer: CN=RapidSSL RSA CA 2018,OU=www.digicert.com,O=DigiCert >>> Inc,C=US >>> >> > > HEAD / HTTP/1.1 >>> >> > > User-Agent: curl/7.29.0 >>> >> > > Host: www.amnetgroup.com >>> >> > > Accept: */* >>> >> > > >>> >> > < HTTP/1.1 502 Bad Gateway >>> >> > HTTP/1.1 502 Bad Gateway >>> >> > < Content-Length: 1477 >>> >> > Content-Length: 1477 >>> >> > < Content-Type: text/html >>> >> > Content-Type: text/html >>> >> > < Server: Microsoft-IIS/10.0 >>> >> > Server: Microsoft-IIS/10.0 >>> >> > < Date: Tue, 07 Jan 2020 04:54:33 GMT >>> >> > Date: Tue, 07 Jan 2020 04:54:33 GMT >>> >> > >>> >> > < >>> >> > * Connection #0 to host www.amnetgroup.com left intact >>> >> > >>> >> > >>> >> > Also I ran the openssl command suggested by you and it showed below >>> output.However it showed the details of the older certificate and not the >>> newer certificate. >>> >> > >>> >> > CONNECTED(00000003) >>> >> > depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = >>> DigiCert Global Root CA >>> >> > verify return:1 >>> >> > depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = >>> RapidSSL RSA CA 2018 >>> >> > verify return:1 >>> >> > depth=0 CN = *.amnetgroup.com >>> >> > verify return:1 >>> >> > --- >>> >> > Certificate chain >>> >> > 0 s:/CN=*.amnetgroup.com >>> >> > i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=RapidSSL RSA CA >>> 2018 >>> >> > --- >>> >> > Server certificate >>> >> > -----BEGIN CERTIFICATE----- >>> >> > omitted details by me >>> >> > -----END CERTIFICATE----- >>> >> > subject=/CN=*.amnetgroup.com >>> >> > issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=RapidSSL RSA CA >>> 2018 >>> >> > --- >>> >> > No client certificate CA names sent >>> >> > Peer signing digest: SHA256 >>> >> > Server Temp Key: ECDH, P-256, 256 bits >>> >> > --- >>> >> > SSL handshake has read 1957 bytes and written 415 bytes >>> >> > --- >>> >> > New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 >>> >> > Server public key is 2048 bit >>> >> > Secure Renegotiation IS supported >>> >> > Compression: NONE >>> >> > Expansion: NONE >>> >> > No ALPN negotiated >>> >> > SSL-Session: >>> >> > Protocol : TLSv1.2 >>> >> > Cipher : ECDHE-RSA-AES256-GCM-SHA384 >>> >> > Session-ID: >>> 25060000435F5A20DC3729228EDBAFE8DC304C5AF2E0EEF462E7E6683C260F2E >>> >> > Session-ID-ctx: >>> >> > Master-Key: >>> FF6322B425CB9D1ED3ABD7430D006DAE58B167BB06602B7FBA958F6511C03321B6FF385FD5543A047760769BE196B4EA >>> >> > Key-Arg : None >>> >> > Krb5 Principal: None >>> >> > PSK identity: None >>> >> > PSK identity hint: None >>> >> > Start Time: 1578373675 >>> >> > Timeout : 300 (sec) >>> >> > Verify return code: 0 (ok) >>> >> > --- >>> >> > >>> >> > Regards >>> >> > Sachin Kumar >>> >> > >>> >> > On Mon, Jan 6, 2020 at 9:36 PM Daniel Ferradal < >>> [email protected]> wrote: >>> >> >> >>> >> >> Who is reporting a 502 exactly? >>> >> >> >>> >> >> Perhaps we are missing the entire chain of events to properly >>> diagnose >>> >> >> the issue. >>> >> >> >>> >> >> If the problem is a client reporting an issue while proxying to >>> this >>> >> >> server try manually to access ther web server yourself to discard >>> >> >> issues: >>> >> >> >>> >> >> curl -vI https://www.amnetgroup.com >>> >> >> >>> >> >> also you can manually try: >>> >> >> >>> >> >> openssl s_client connect www.amnetgroup.com:443 >>> >> >> >>> >> >> and see if those tools report an issue. >>> >> >> >>> >> >> If the above works well, it may be client issue, some clients can >>> not >>> >> >> distinguish wildcard certificates. I know you said it is the same >>> >> >> certificate name, etc but better recheck the whole chain of events, >>> >> >> httpd knows how to match CN to wildcard certificates and like >>> >> >> mentioned earlier, it usually is up to picky clients complaining >>> about >>> >> >> mismatches because they don't know how to deal with wildcard >>> >> >> certificates (lots of java applications, for example). >>> >> >> >>> >> >> Also consider, if server has an issue with the certificate name it >>> >> >> will mention it or fail silently unless debugging is enabled for >>> ssl >>> >> >> module. >>> >> >> >>> >> >> Briefly: >>> >> >> >>> >> >> * If httpd sees a difference between CN and ServerName, then there >>> >> >> really is a difference, make sure the correct cert is installed. >>> >> >> * If the wrong certificate (wrong name) is installed it will do the >>> >> >> same as above. >>> >> >> * If key and crt installed mistmatched it won't even start and fail >>> >> >> silently. (so do make sure httpd is starting when you install the >>> new >>> >> >> certificate). >>> >> >> * If the certificate is correct and client is complaining, it >>> probably >>> >> >> is a client which can't distinguish wildcard names, but this is >>> not an >>> >> >> issue, it is a client not prepared for wildcard certificates (java >>> >> >> apps just need to specify a correct hostname verifier or no >>> hostname >>> >> >> verification at all). >>> >> >> >>> >> >> There isn't much more to this than what I described, so pay careful >>> >> >> attention and make sure httpd starts. >>> >> >> >>> >> >> El lun., 6 ene. 2020 a las 14:32, Sac Isilia >>> >> >> (<[email protected]>) escribió: >>> >> >> > >>> >> >> > Hi Martin, >>> >> >> > >>> >> >> > Below is the attribute of the existing working certificate. The >>> only difference is that the new certificate is of validity 2 years , but >>> that should not be an issue. >>> >> >> > We performed below steps while updating - >>> >> >> > >>> >> >> > 1.openssl req -newkey rsa:2048 -nodes -keyout amnetgroup.com.key >>> -out amnetgroup.com.csr -- Generated the csr >>> >> >> > 2. Send it to the concerned organization and got the updated >>> PKCS#7 certificate.(in the form of .p7b file) >>> >> >> > 3. Extracted the certificate - openssl pkcs7 -inform der >>> -print_certs -in Amnetgroup.p7b -out amnetgroupnew.com.crt >>> >> >> > 4. Updated the certificate content and the private key and the >>> bundle file was updated too that came along with it. >>> >> >> > 5. Restarted the httpd service. And Alas!! website was throwing >>> error that I mentioned earlier. >>> >> >> > >>> >> >> > Certificate: >>> >> >> > Data: >>> >> >> > Version: 3 (0x2) >>> >> >> > Serial Number: >>> >> >> > 0b:1a:d3:af:3f:7d:ab:ea:7d:0a:b9:23:99:b1:bf:27 >>> >> >> > Signature Algorithm: sha256WithRSAEncryption >>> >> >> > Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, >>> CN=RapidSSL RSA CA 2018 >>> >> >> > Validity >>> >> >> > Not Before: Jan 23 00:00:00 2019 GMT >>> >> >> > Not After : Jan 23 12:00:00 2020 GMT >>> >> >> > Subject: CN=*.amnetgroup.com >>> >> >> > >>> >> >> > X509v3 Subject Alternative Name: >>> >> >> > DNS:*.amnetgroup.com, DNS:amnetgroup.com >>> >> >> > >>> >> >> > Below is the attribute of the new certificate of which update is >>> failing. >>> >> >> > >>> >> >> > Certificate: >>> >> >> > Data: >>> >> >> > Version: 3 (0x2) >>> >> >> > Serial Number: >>> >> >> > 0a:8f:61:f5:6f:8c:8b:ce:95:c2:d5:c5:79:8d:2b:d9 >>> >> >> > Signature Algorithm: sha256WithRSAEncryption >>> >> >> > Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, >>> CN=RapidSSL RSA CA 2018 >>> >> >> > Validity >>> >> >> > Not Before: Jan 3 00:00:00 2020 GMT >>> >> >> > Not After : Mar 3 12:00:00 2022 GMT >>> >> >> > Subject: CN=*.amnetgroup.com >>> >> >> > >>> >> >> > X509v3 Subject Alternative Name: >>> >> >> > DNS:*.amnetgroup.com, DNS:amnetgroup.com >>> >> >> > >>> >> >> > Regards >>> >> >> > Sachin Kumar >>> >> >> > >>> >> >> > >>> >> >> > On Mon, Jan 6, 2020 at 6:34 PM Martin Drescher < >>> [email protected]> wrote: >>> >> >> >> >>> >> >> >> Hi Sachin, >>> >> >> >> >>> >> >> >> as long as I am doing this, a non matching CN and/or v3 >>> SubjectAlternativeNames never effected the HTTP server in a way, that it >>> wpold stop working for me. Both messeges you quoted, ah02292 and ah01909 >>> are warning messages. They *may* effect your client's behavior. Hence, if >>> there is not a person in this list knowing better, this should not be of >>> your concern. >>> >> >> >> >>> >> >> >> What about that 502? This looks like your real issue to me. >>> >> >> >> >>> >> >> >> However, I remember reading some stuff changed (or will >>> change?) in regard of VirtualHost clause. But even this would not make >>> sense, if your old certificate is still working. Next thing you could do >>> is, look for changes int the certificate's attributes. May be there is a >>> change, that should not be there. >>> >> >> >> >>> >> >> >> >>> >> >> >> Am 04.01.20 um 18:02 schrieb Sac Isilia: >>> >> >> >> > Hi Team, >>> >> >> >> > >>> >> >> >> >>> >> >> >> [...] >>> >> >> >> >>> >> >> >> > *502 - Web server received an invalid response while acting >>> as a gateway or >>> >> >> >> > proxy server.* >>> >> >> >> > >>> >> >> >> > *There is a problem with the page you are looking for, and it >>> cannot be >>> >> >> >> > displayed.* >>> >> >> >> > >>> >> >> >> > *When the Web server (while acting as a gateway or proxy) >>> contacted the >>> >> >> >> > upstream content server, it received an invalid response from >>> the content >>> >> >> >> > server.”* >>> >> >> >> > >>> >> >> >> > In the error logs I have found below messages . >>> >> >> >> > >>> >> >> >> > ah02292: init: name-based ssl virtual hosts only work for >>> clients with tls >>> >> >> >> > server name indication support >>> >> >> >> > >>> >> >> >> > ah01909: rsa certificate configured for xxxxxxxxxxx:443 does >>> not include an >>> >> >> >> > id which matches the server name >>> >> >> >> > >>> >> >> >> > Please help me in resolving this issue. >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > Regards >>> >> >> >> > >>> >> >> >> > Sachin Kumar >>> >> >> >> > >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> Martin >>> >> >> >> >>> >> >> >>> >> >> >>> >> >> -- >>> >> >> Daniel Ferradal >>> >> >> HTTPD Project >>> >> >> #httpd help at Freenode >>> >> >> >>> >> >> >>> --------------------------------------------------------------------- >>> >> >> To unsubscribe, e-mail: [email protected] >>> >> >> For additional commands, e-mail: [email protected] >>> >> >> >>> >> >>> >> >>> >> -- >>> >> Daniel Ferradal >>> >> HTTPD Project >>> >> #httpd help at Freenode >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: [email protected] >>> >> For additional commands, e-mail: [email protected] >>> >> >>> >>> >>> -- >>> Daniel Ferradal >>> HTTPD Project >>> #httpd help at Freenode >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> > > -- > Daniel Ferradal > HTTPD Project > #httpd help at Freenode >
