httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Ferradal <dferra...@apache.org>
Subject Re: [users@httpd] SSL certificate update failed - httpd-2.4.6-90.el7
Date Tue, 07 Jan 2020 13:43:45 GMT
Hello,

1º the way to verify is the openssl commands we mentioned earlier.
2º no, you clearly do not have that in the server that reports those
warnings, or if you do, that virtualhost is alright and the problem is the
other virtualhosts that report the warning, like:
amdc2webl06.dmz.local:443  <--- and all those that report warnings, clearly
dmz.local does not match *.amnetgroup.com

I can suggest you check all virtualhosts configured, there is a command you
can use that will yell you the virtualhosts configured:
"apachectl -S"

El mar., 7 ene. 2020 a las 14:38, Sac Isilia (<udaypratap.singh65@gmail.com>)
escribió:

> Hi Daniel ,
>
> That makes sense. I will needing help as I have very less knowledge of
> Apache and instead messing things up please help me in below queries.
>
> "you probably are using the public name but the certs you are really using
> are local names or the opposite" - How to verify this on the Linux.
> "mismatches between "ServerName" directive and the CN in the certificate
> are different" - ServerName is www.amnetgroup.com and CN is *.
> amnetgroup.com and it works perfectly for the existing certificate
> without adding the Alias directive.
>
> make clients connecting ignore the name mismatches  - How to do that for
> Chrome
>
> Regards
> Sachin Kumar
>
>
>
> On Tue, Jan 7, 2020 at 6:58 PM Daniel Ferradal <dferradal@apache.org>
> wrote:
>
>> Hello,
>>
>> The key to your certificate issues lies in the warning messages like this
>> one:
>>
>> AH01909: RSA certificate configured for amdc2webl06.dmz.local:443 does
>> NOT include an ID which matches the server name.
>>
>> So you probably are using the public name but the certs you are really
>> using are local names or the opposite, either case there are name
>> mismatches between "ServerName" directive and the CN in the certificate are
>> different, that's all there is to it.
>>
>> Having said that, it is not an issue that blocks the usage of SSL, just
>> that clients connecting to SSL will complain about it, like I mentioned
>> earlier.
>>
>> So you have to options, either you fix the name mismatches by configuring
>> the appropiate ServerName or installing the appropiate certificates for
>> those names, or make clients connecting ignore the name mismatches, either
>> way SSL is functional.
>>
>> Picture this as if I am trying to talk to you and you identify with a
>> name I don't recognize or that is clearly not the one I am using to address
>> you in the frst place, I can still talk to you, or I can refuse to talk to
>> you due to mistrust, either way, we have the ability to talk (we can
>> perfectly have SSL encrypted connection) to each other and nothing else
>> than a "trust" issue may prevent us from doing so.
>>
>> El mar., 7 ene. 2020 a las 14:12, Sac Isilia (<
>> udaypratap.singh65@gmail.com>) escribió:
>>
>>> 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 <dferradal@apache.org>
>>> 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 (<
>>>> udaypratap.singh65@gmail.com>) 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 <dferradal@apache.org>
>>>>> 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
>>>>>> (<udaypratap.singh65@gmail.com>) 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, <dferradal@apache.org>
>>>>>> 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
>>>>>> >> (<udaypratap.singh65@gmail.com>) 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 <
>>>>>> 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
>>>>>> >> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> 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
>>>>>> >>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Daniel Ferradal
>>>> HTTPD Project
>>>> #httpd help at Freenode
>>>>
>>>
>>
>> --
>> Daniel Ferradal
>> HTTPD Project
>> #httpd help at Freenode
>>
>

-- 
Daniel Ferradal
HTTPD Project
#httpd help at Freenode

Mime
View raw message