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]
