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]
