httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sac Isilia <udaypratap.sing...@gmail.com>
Subject Re: [users@httpd] SSL certificate update failed - httpd-2.4.6-90.el7
Date Tue, 07 Jan 2020 05:10:42 GMT
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 <dferradal@apache.org> 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
> (<udaypratap.singh65@gmail.com>) 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 <drescher@inter.net>
> 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: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>

Mime
View raw message