SSO SPNEGO GSS API CheckSum Failed Error
Hi all, I have a redhat 9.2 server hosting a web application on 5 seperate instances of Apache Tomcat. I have configured SPNEGO on instances 1,2,3 and 4. These instances are behind an apache proxy load balancer on version 2.4.57. Instance 1,2, and 3 are load balanced. While 4 and 5 are not. The application is hosted on Tomcat 9.0.54. Domain: domain.com Site: devexample.domain.com URL hit: https://devexample.domain.com/webclient_devex/exclient.jsp *I keep getting this when accessing the application on instance 5:* HTTP Status 500 – Internal Server Error Type Exception Report Message GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed) Description The server encountered an unexpected condition that prevented it from fulfilling the request. Exception javax.servlet.ServletException: GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed) net.sourceforge.spnego.SpnegoHttpFilter.doFilter(SpnegoHttpFilter.java:287) Root Cause GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed) sun.security.jgss.krb5.Krb5Context.acceptSecContext(Unknown Source) sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(Unknown Source) sun.security.jgss.spnego.SpNegoContext.acceptSecContext(Unknown Source) sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) net.sourceforge.spnego.SpnegoAuthenticator.doSpnegoAuth(SpnegoAuthenticator.java:487) net.sourceforge.spnego.SpnegoAuthenticator.authenticate(SpnegoAuthenticator.java:327) net.sourceforge.spnego.SpnegoHttpFilter.doFilter(SpnegoHttpFilter.java:283) Root Cause KrbException: Checksum failed sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType.decrypt(Unknown Source) sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType.decrypt(Unknown Source) sun.security.krb5.EncryptedData.decrypt(Unknown Source) sun.security.krb5.KrbApReq.authenticate(Unknown Source) sun.security.krb5.KrbApReq.(Unknown Source) sun.security.jgss.krb5.InitSecContextToken.(Unknown Source) sun.security.jgss.krb5.Krb5Context.acceptSecContext(Unknown Source) sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(Unknown Source) sun.security.jgss.spnego.SpNegoContext.acceptSecContext(Unknown Source) sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) net.sourceforge.spnego.SpnegoAuthenticator.doSpnegoAuth(SpnegoAuthenticator.java:487) net.sourceforge.spnego.SpnegoAuthenticator.authenticate(SpnegoAuthenticator.java:327) net.sourceforge.spnego.SpnegoHttpFilter.doFilter(SpnegoHttpFilter.java:283) Root Cause java.security.GeneralSecurityException: Checksum failed sun.security.krb5.internal.crypto.dk.AesDkCrypto.decryptCTS(Unknown Source) sun.security.krb5.internal.crypto.dk.AesDkCrypto.decrypt(Unknown Source) sun.security.krb5.internal.crypto.Aes256.decrypt(Unknown Source) sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType.decrypt(Unknown Source) sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType.decrypt(Unknown Source) sun.security.krb5.EncryptedData.decrypt(Unknown Source) sun.security.krb5.KrbApReq.authenticate(Unknown Source) sun.security.krb5.KrbApReq.(Unknown Source) sun.security.jgss.krb5.InitSecContextToken.(Unknown Source) sun.security.jgss.krb5.Krb5Context.acceptSecContext(Unknown Source) sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(Unknown Source) sun.security.jgss.spnego.SpNegoContext.acceptSecContext(Unknown Source) sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) net.sourceforge.spnego.SpnegoAuthenticator.doSpnegoAuth(SpnegoAuthenticator.java:487) net.sourceforge.spnego.SpnegoAuthenticator.authenticate(SpnegoAuthenticator.java:327) net.sourceforge.spnego.SpnegoHttpFilter.doFilter(SpnegoHttpFilter.java:283) In the catalina logs: Entered SpNegoContext.acceptSecContext with state=STATE_NEW SpNegoContext.acceptSecContext: receiving token = a0 82 07 f1 30 82 07 ed a0 30 30 2e 06 09 2a 86 48 82 f7 12 01 02 02 06 09 2a 86 48 86 f7 12 01 02 02 06 0a 2b 06 01 04 01 82 37 02 02 1e 06 0a 2b 06 01 04 01 82 37 02 02 0a a2 82 07 b7 04 82 07 b3 60 82 07 af 06 09 2a 86 48 86 f7 12 01 02 02 01 00 6e 82 07 9e 30 82 07 9a a0 03 02 01 05 a1 03 02 01 0e a2 07 03 05 00 20 00 00 00 a3 82 05 a4 61 82 05 a0 30 82 05 9c a0 03 02 01 05 a1 15 1b 13 52 45 41 4c 4c 59 47 4f 4f 44 53 54 55 46 46 2e 43 4f 4d a2 30 30 2e a0 03 02 01 02 a1 27 30 25 1b 04 48 54 54 50 1b 1d 72
Re: HTTPD pass off delegation credentials to Apache Tomcat 8.5.23 for SSO Kerberos
André,
I was able to use the reference you made about making tomcatAuthentication
false. With this Tomcat setting combined with HTTPD's mod_proxy_ajp proxy
rules I was able to get this working. I am still testing this but looks
clear to me that this is the solution. Thanks for the quick responses
yesterday!
On Wed, Sep 19, 2018 at 5:10 PM André Warnier (tomcat)
wrote:
> Hi.
> Much better..
> I don't know if I will be able to help you, considering my little
> knowledge of Kerberos,
> but I'm sure that someone else now will be.
>
> On 19.09.2018 16:08, Thomas Delaney wrote:
> > Here is more detail into what I went through for setting up Apache
> Tomcat.:
> > I configured each Apache Tomcat instance using this bit of documentation:
> > SPNEGO
> > http://spnego.sourceforge.net/
> >
> > I also used this documentation in order to get my workstation to accept
> > Kerberos authentication and not default to NTLM.
> >
> https://ping.force.com/Support/PingFederate/Integrations/How-to-configure-supported-browsers-for-Kerberos-NTLM
> >
> > *I created/configured the following based on what was outlined from the
> > SPNEGO doc:*
> > login.conf
> > krb.conf
> > HelloKDC.java successfully connected when testing
> > The SPNEGO filter in Apache Tomcat's web.xml
> > Took the source code for spnego.jar and placed it in Apache Tomcat's
> library
> > hello_spnego.jsp successfully displayed the correct remote user on the
> web
> > page
> > hello_delegate.jsp successfully displayed the correct delegated
> credentials
> > on the webpage.
>
> Ok, so we can assume
> - that the basic Kerberos infrastructure works
> - that you know how to set it up
> - and that it works when you do the Kerberos authentication in Tomcat
> itself, and access
> tomcat directly from the browser.
>
> >
> > Once I was able to verify that the above steps worked on Apache Tomcat. I
> > tested the same web pages on Apache HTTPD.
>
> You mean "when accessing Tomcat /through/ the Apache httpd front-end,
> right ?
>
> From your original description, I thought that you wanted to do the
> Kerberos
> authentication in the front-end Apache httpd, and pass on the
> authenticated user-id to the
> back-end Tomcats then. That's still an option anyway.
> But from the description below it looks like you want to keep the
> SPNEGO/Kerberos
> authentication at the Tomcat level, and just want the front-end httpd to
> be "transparent"
> with respect to the Kerberos authentication exchanges.
> Do I get this right ?
>
> I ran into issues when testing
> > hello_spnego.jsp and hello_delegate.jsp.
> >
> > Here have been my results:
> > hello_spnego.jsp -> "hello root !" (root being a unix user and not the
> > AD/Windows user signed onto the domain).
> > hello_delegate.jsp -> "No delegated creds."
> >
> > *Here is the section of the SPNEGO doc source on how to setup
> > hello_delegation.jsp and create hello_spnego.jsp:*
> > http://spnego.sourceforge.net/credential_delegation.html
>
> Mmm. This is quite complicated, but I think that I'm starting to guess
> what the problem is.
> I think that "delegation" is not really what you want to do here. It might
> work in the
> absolute (if everything was set up correctly to do it), but I believe that
> it is overkill
> in your case; and I believe that you are missing one piece of the puzzle
> anyway.
>
> Taking into account my total lack of experience with SPNEGO/Kerberos
> delegation - and thus
> taking this with a grain of salt - I believe (from the above documentation
> page) that for
> such a delegation to work with an Apache httpd front-end, your browser
> would /first/ need
> to be authenticated already by the front-end (for example, "as you"), and
> that this
> front-end /itself/ would need to have /its own (separate) account/ in your
> infrastructure
> - and an account with special properties - in order to be allowed to
> authenticate "as you"
> (otherwise said : "impersonate you") with the Tomcat back-end's
> SPNEGO/Kerberos Valve.
>
> >
> > *Here is how I have Apache HTTPD forwarding requests to Tomcat. *
> > Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/"
> > env=BALANCER_ROUTE_CHANGED
> >
> > BalancerMember "http://localhost:8081/application; route=node1
> > BalancerMember "http://localhost:8082/application; route=node2
> > BalancerMember "http://localhost:8083/application; route=node3
> > ProxySet lbmethod=byrequests stickysession=ROUTEID
>
Re: HTTPD pass off delegation credentials to Apache Tomcat 8.5.23 for SSO Kerberos
Here is more detail into what I went through for setting up Apache Tomcat.:
I configured each Apache Tomcat instance using this bit of documentation:
SPNEGO
http://spnego.sourceforge.net/
I also used this documentation in order to get my workstation to accept
Kerberos authentication and not default to NTLM.
https://ping.force.com/Support/PingFederate/Integrations/How-to-configure-supported-browsers-for-Kerberos-NTLM
*I created/configured the following based on what was outlined from the
SPNEGO doc:*
login.conf
krb.conf
HelloKDC.java successfully connected when testing
The SPNEGO filter in Apache Tomcat's web.xml
Took the source code for spnego.jar and placed it in Apache Tomcat's library
hello_spnego.jsp successfully displayed the correct remote user on the web
page
hello_delegate.jsp successfully displayed the correct delegated credentials
on the webpage.
Once I was able to verify that the above steps worked on Apache Tomcat. I
tested the same web pages on Apache HTTPD. I ran into issues when testing
hello_spnego.jsp and hello_delegate.jsp.
Here have been my results:
hello_spnego.jsp -> "hello root !" (root being a unix user and not the
AD/Windows user signed onto the domain).
hello_delegate.jsp -> "No delegated creds."
*Here is the section of the SPNEGO doc source on how to setup
hello_delegation.jsp and create hello_spnego.jsp:*
http://spnego.sourceforge.net/credential_delegation.html
*Here is how I have Apache HTTPD forwarding requests to Tomcat. *
Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/"
env=BALANCER_ROUTE_CHANGED
BalancerMember "http://localhost:8081/application; route=node1
BalancerMember "http://localhost:8082/application; route=node2
BalancerMember "http://localhost:8083/application; route=node3
ProxySet lbmethod=byrequests stickysession=ROUTEID
ProxyPass /application balancer://application/
ProxyPassReverse /application balancer://application/
On Wed, Sep 19, 2018 at 7:57 AM André Warnier (tomcat)
wrote:
> On 18.09.2018 23:24, Thomas Delaney wrote:
> > Hello All,
> >
> > I have recently configured Apache Tomcat on a SuSe Enterprise 12 SP3
> server
> > to get Kerberos SSO working with a web client application. I have also in
> > addition configured Apache HTTPD 2.4.29 on the same machine.When I reach
> > that website I am failing to get SSO working. The web server is not
> passing
> > off the delegation credentials to Apache Tomcat server. I have the web
> > server load balance proxying it's request to multiple Apache Tomcat
> > instances. I have tried applying mody_proxy_http environment variables,
> but
> > the site continues to fail SSO. Is there a guide or configuration that
> > HTTPD and Apache Tomcat both use to involve Apache HTTPD passing off
> > delegation credentials to Apache Tomcat?
> >
>
> If you would like someone here to be able to help you, you would need to
> be much more
> precise than that. You write "I have done this" and "I have done that",
> but without
> giving any clue as to /how/ you did this or that.
> You are not even saying /where/ you have configured the Kerberos SSO.
> Under the Apache
> httpd front-end ? or under Tomcat ?
>
> To point you nevertheless in a possible direction, read this :
>
> https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Apache_httpd
> (and, in your mind, substitute "Windows authentication" by "Kerberos
> authentication")
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
HTTPD pass off delegation credentials to Apache Tomcat 8.5.23 for SSO Kerberos
Hello All, I have recently configured Apache Tomcat on a SuSe Enterprise 12 SP3 server to get Kerberos SSO working with a web client application. I have also in addition configured Apache HTTPD 2.4.29 on the same machine.When I reach that website I am failing to get SSO working. The web server is not passing off the delegation credentials to Apache Tomcat server. I have the web server load balance proxying it's request to multiple Apache Tomcat instances. I have tried applying mody_proxy_http environment variables, but the site continues to fail SSO. Is there a guide or configuration that HTTPD and Apache Tomcat both use to involve Apache HTTPD passing off delegation credentials to Apache Tomcat? Thanks!
Re: Apache Tomcat 8.5.24 SSL Configuration
I apologize for the poor grammar in my last response and extra email. The site I have setup is internal only. I will not be able to test the site using SSL Labs. On Fri, Dec 22, 2017 at 9:37 AM, Thomas Delaney <tdelaney@gmail.com> wrote: > The site is internal so I won't not be able to check via ssllabs > > On Thu, Dec 21, 2017 at 5:36 PM, George S. <geor...@mhsoftware.com> wrote: > >> On 12/21/2017 3:24 PM, Thomas Delaney wrote: >> >>> Thank you for the input so far! >>> >>> I have used both java versions jdk 1.7.0_79 and jdk1.8.0_152 and still >>> receive the same result >>> >>> when running the openssl s_client command I recieved this as the Cipher >>> and >>> SSL version >>> Protocol : TLSv1.2 >>> Cipher: DHE-RSA-AES256-GCM-SHA384 >>> >>> I also get a message saying "verify error:num=20:unable to get local >>> issuer certificate" >>> "Verify return code: 20 (unable to get local issuer certificate)" >>> >> >> I second Chris Schultz's recommendation that you run the site through the >> SSL Labs testing site and see what it points out. It's going to check a lot >> more things right off the bat and display them in an easier format: >> >> https://www.ssllabs.com/ssltest/ >> >> >> >> >> >>> On Thu, Dec 21, 2017 at 2:31 PM, Christopher Schultz < >>> ch...@christopherschultz.net> wrote: >>> >>> -BEGIN PGP SIGNED MESSAGE- >>>> Hash: SHA256 >>>> >>>> Peter, >>>> >>>> On 12/21/17 2:38 AM, l...@kreuser.name wrote: >>>> >>>>> Hi Thomas, >>>>> >>>>> Am 21.12.2017 um 00:56 schrieb Thomas Delaney >>>>>> <tdelaney@gmail.com>: >>>>>> >>>>>> Greetings, >>>>>> >>>>>> I am having trouble regarding google chrome's behavior to Apache >>>>>> Tomcat's SSL setup. I have been successful getting an ssl website >>>>>> to work with Apache HTTP web server, but not Apache Tomcat 8.5.24 >>>>>> on google chrome. Mozilla Firefox brings me to my site with no >>>>>> problem. >>>>>> >>>>>> When going to https://mydomain.com:8443 I recieve a message from >>>>>> Google Chrome. >>>>>> >>>>>> Google Chrome Error - This site can’t provide a secure >>>>>> connection mydomain.com uses an unsupported protocol. >>>>>> ERR_SSL_VERSION_OR_CIPHER_MISMATCH >>>>>> >>>>>> Unsupported protocol The client and server don't support a common >>>>>> SSL protocol version or cipher suite. >>>>>> >>>>>> When checking Google Chrome's Browser console in the security tab >>>>>> I recieve: Page is not secure Valid certificate secure resources >>>>>> >>>>>> Here is the following background info I have for the >>>>>> configuration I gave Apache Tomcat when setting up the 8443 >>>>>> connector >>>>>> >>>>>> Chrome Version 63.0.3239.108 (Official Build) (64-bit) >>>>>> >>>>>> Linux OS: SUSE Enterprise 12 sp1 >>>>>> >>>>>> Packages installed: >>>>>> >>>>>> - OpenSSL 1.0.2n 7 Dec 2017 - jdk version 1.7.0_79 >>>>>> >>>>> That may be the culprit. >>>>> >>>>> Apparently this (old) version of Java7 will not provide in the >>>>> default modern ciphers that Chrome requires. And the config is >>>>> using the JSSE SSL implementation. But as you have TC Native and >>>>> openssl 1.0.2 you should switch to openssl. >>>>> >>>> This probably isn't the problem since Thomas is using the APR >>>> connector. TLS cipher suite support (or lack thereof) from Java 1.7 is >>>> not relevant. >>>> >>>> - tomcat version -> apache-tomcat-8.5.24 - apr-1.6.3 - >>>>>> tomcat-native-1.2.16-src >>>>>> >>>>>> Server.xml apr connector (Certificates are signed from GoDaddy >>>>>> and are placed in the conf directory of Apache Tomcat): >>>>>> >>>>>> >>>>> protocol="org.apache.coyote.http11.Htt
Re: Apache Tomcat 8.5.24 SSL Configuration
The site is internal so I won't not be able to check via ssllabs On Thu, Dec 21, 2017 at 5:36 PM, George S. <geor...@mhsoftware.com> wrote: > On 12/21/2017 3:24 PM, Thomas Delaney wrote: > >> Thank you for the input so far! >> >> I have used both java versions jdk 1.7.0_79 and jdk1.8.0_152 and still >> receive the same result >> >> when running the openssl s_client command I recieved this as the Cipher >> and >> SSL version >> Protocol : TLSv1.2 >> Cipher: DHE-RSA-AES256-GCM-SHA384 >> >> I also get a message saying "verify error:num=20:unable to get local >> issuer certificate" >> "Verify return code: 20 (unable to get local issuer certificate)" >> > > I second Chris Schultz's recommendation that you run the site through the > SSL Labs testing site and see what it points out. It's going to check a lot > more things right off the bat and display them in an easier format: > > https://www.ssllabs.com/ssltest/ > > > > > >> On Thu, Dec 21, 2017 at 2:31 PM, Christopher Schultz < >> ch...@christopherschultz.net> wrote: >> >> -----BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA256 >>> >>> Peter, >>> >>> On 12/21/17 2:38 AM, l...@kreuser.name wrote: >>> >>>> Hi Thomas, >>>> >>>> Am 21.12.2017 um 00:56 schrieb Thomas Delaney >>>>> <tdelaney@gmail.com>: >>>>> >>>>> Greetings, >>>>> >>>>> I am having trouble regarding google chrome's behavior to Apache >>>>> Tomcat's SSL setup. I have been successful getting an ssl website >>>>> to work with Apache HTTP web server, but not Apache Tomcat 8.5.24 >>>>> on google chrome. Mozilla Firefox brings me to my site with no >>>>> problem. >>>>> >>>>> When going to https://mydomain.com:8443 I recieve a message from >>>>> Google Chrome. >>>>> >>>>> Google Chrome Error - This site can’t provide a secure >>>>> connection mydomain.com uses an unsupported protocol. >>>>> ERR_SSL_VERSION_OR_CIPHER_MISMATCH >>>>> >>>>> Unsupported protocol The client and server don't support a common >>>>> SSL protocol version or cipher suite. >>>>> >>>>> When checking Google Chrome's Browser console in the security tab >>>>> I recieve: Page is not secure Valid certificate secure resources >>>>> >>>>> Here is the following background info I have for the >>>>> configuration I gave Apache Tomcat when setting up the 8443 >>>>> connector >>>>> >>>>> Chrome Version 63.0.3239.108 (Official Build) (64-bit) >>>>> >>>>> Linux OS: SUSE Enterprise 12 sp1 >>>>> >>>>> Packages installed: >>>>> >>>>> - OpenSSL 1.0.2n 7 Dec 2017 - jdk version 1.7.0_79 >>>>> >>>> That may be the culprit. >>>> >>>> Apparently this (old) version of Java7 will not provide in the >>>> default modern ciphers that Chrome requires. And the config is >>>> using the JSSE SSL implementation. But as you have TC Native and >>>> openssl 1.0.2 you should switch to openssl. >>>> >>> This probably isn't the problem since Thomas is using the APR >>> connector. TLS cipher suite support (or lack thereof) from Java 1.7 is >>> not relevant. >>> >>> - tomcat version -> apache-tomcat-8.5.24 - apr-1.6.3 - >>>>> tomcat-native-1.2.16-src >>>>> >>>>> Server.xml apr connector (Certificates are signed from GoDaddy >>>>> and are placed in the conf directory of Apache Tomcat): >>>>> >>>>> >>>> protocol="org.apache.coyote.http11.Http11AprProtocol" >>>>> maxThreads="150" SSLEnabled="true" defaultSSLHostConfigName=" >>>>> mydomain.com" > >>>> protocols="TLSv1,TLSv1.1,TLSv1.2"> >>>> certificateKeyFile="conf/server.key" >>>>> certificateFile="conf/server.crt" >>>>> certificateChainFile="conf/CA_server_bundle.crt" type="RSA" /> >>>>> >>>>> >>>> This looks okay to me. If you start Tomcat and then use "openssl >>> s_client -connect :", does openssl connect? It should >>>
Re: Apache Tomcat 8.5.24 SSL Configuration
Thank you for the input so far! I have used both java versions jdk 1.7.0_79 and jdk1.8.0_152 and still receive the same result when running the openssl s_client command I recieved this as the Cipher and SSL version Protocol : TLSv1.2 Cipher: DHE-RSA-AES256-GCM-SHA384 I also get a message saying "verify error:num=20:unable to get local issuer certificate" "Verify return code: 20 (unable to get local issuer certificate)" On Thu, Dec 21, 2017 at 2:31 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Peter, > > On 12/21/17 2:38 AM, l...@kreuser.name wrote: > > > > Hi Thomas, > > > >> Am 21.12.2017 um 00:56 schrieb Thomas Delaney > >> <tdelaney@gmail.com>: > >> > >> Greetings, > >> > >> I am having trouble regarding google chrome's behavior to Apache > >> Tomcat's SSL setup. I have been successful getting an ssl website > >> to work with Apache HTTP web server, but not Apache Tomcat 8.5.24 > >> on google chrome. Mozilla Firefox brings me to my site with no > >> problem. > >> > >> When going to https://mydomain.com:8443 I recieve a message from > >> Google Chrome. > >> > >> Google Chrome Error - This site can’t provide a secure > >> connection mydomain.com uses an unsupported protocol. > >> ERR_SSL_VERSION_OR_CIPHER_MISMATCH > >> > >> Unsupported protocol The client and server don't support a common > >> SSL protocol version or cipher suite. > >> > >> When checking Google Chrome's Browser console in the security tab > >> I recieve: Page is not secure Valid certificate secure resources > >> > >> Here is the following background info I have for the > >> configuration I gave Apache Tomcat when setting up the 8443 > >> connector > >> > >> Chrome Version 63.0.3239.108 (Official Build) (64-bit) > >> > >> Linux OS: SUSE Enterprise 12 sp1 > >> > >> Packages installed: > >> > >> - OpenSSL 1.0.2n 7 Dec 2017 - jdk version 1.7.0_79 > > > > That may be the culprit. > > > > Apparently this (old) version of Java7 will not provide in the > > default modern ciphers that Chrome requires. And the config is > > using the JSSE SSL implementation. But as you have TC Native and > > openssl 1.0.2 you should switch to openssl. > > This probably isn't the problem since Thomas is using the APR > connector. TLS cipher suite support (or lack thereof) from Java 1.7 is > not relevant. > > >> - tomcat version -> apache-tomcat-8.5.24 - apr-1.6.3 - > >> tomcat-native-1.2.16-src > >> > >> Server.xml apr connector (Certificates are signed from GoDaddy > >> and are placed in the conf directory of Apache Tomcat): > >> > >> >> protocol="org.apache.coyote.http11.Http11AprProtocol" > >> maxThreads="150" SSLEnabled="true" defaultSSLHostConfigName=" > >> mydomain.com" > >> protocols="TLSv1,TLSv1.1,TLSv1.2"> >> certificateKeyFile="conf/server.key" > >> certificateFile="conf/server.crt" > >> certificateChainFile="conf/CA_server_bundle.crt" type="RSA" /> > >> > > This looks okay to me. If you start Tomcat and then use "openssl > s_client -connect :", does openssl connect? It should > report the protocol and cipher suite being used to connect. > > If you server is externally-accessible, consider using an external TLS > capabilities scanner such as that from Qualys, > https://www.ssllabs.com/ssltest/ > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlo8C/0dHGNocmlzQGNo > cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFiayA//Ugc6nwLR2yddEvDc > eqwBYhDib1AZlx2m2iju1tBngWu8Wr/x+MsHTZq+tTzKqPXrvXeTqd3AiBVZhBFf > 8mwGZdf7dmcXZeCYgAVk+p7QxWpPt0hM27KJPeSXNCclrkG3REAPf5XkQBJx6Spr > W7/JbejXooYl27D6+iHg+SsaMNnMuq1nPm0kCP1UyEN40bHzWqHfZbtgfi+wrKB+ > ldJ/fRzMdUO+FMWosuCteHL5CoDotTUSuztWtjGA/raXgX2UJg1LvKxmhYU8mcA1 > noMdpbQX6wYP/XtcKvIplHUJj8UUgZbe5bndDLw7HV2Im3wdN/659GpdAbEBN9EY > O1gQRLVIyvO0XuY7RpDP7RNjbw8Sp7H1Y2Ptou3yJ3dezRQz9vi9M8i78OeEEfMp > 5ZfxaN+bZoT0WteHpbR243DcFzO+HbShPEiSL0zKlltR2qzWBMXd+9XjjkIU8JeF > mfqxdN6HBS5YXOT0IJcd6+uw3FTh2vPEf64K5r4hpIsWxvpmbkYqNIf4GQGuqS7c > nm6gsOP6Wd/PiL67mVClJ6cN9LEPEqxs2QivK2/zzBcmYunXQK0GAbi25C5tG9Ha > 4zB5VuRo0IjPmEKnRuqfZ2KcOVCQaJFbWgV0dJ9UWb7vO5662hYvSssX7jS6or5e > /aq7VBV+GiEaWzZweAi8/k4R3wk= > =DEHk > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Apache Tomcat 8.5.24 SSL Configuration
Greetings, I am having trouble regarding google chrome's behavior to Apache Tomcat's SSL setup. I have been successful getting an ssl website to work with Apache HTTP web server, but not Apache Tomcat 8.5.24 on google chrome. Mozilla Firefox brings me to my site with no problem. When going to https://mydomain.com:8443 I recieve a message from Google Chrome. Google Chrome Error - This site can’t provide a secure connection mydomain.com uses an unsupported protocol. ERR_SSL_VERSION_OR_CIPHER_MISMATCH Unsupported protocol The client and server don't support a common SSL protocol version or cipher suite. When checking Google Chrome's Browser console in the security tab I recieve: Page is not secure Valid certificate secure resources Here is the following background info I have for the configuration I gave Apache Tomcat when setting up the 8443 connector Chrome Version 63.0.3239.108 (Official Build) (64-bit) Linux OS: SUSE Enterprise 12 sp1 Packages installed: - OpenSSL 1.0.2n 7 Dec 2017 - jdk version 1.7.0_79 - tomcat version -> apache-tomcat-8.5.24 - apr-1.6.3 - tomcat-native-1.2.16-src Server.xml apr connector (Certificates are signed from GoDaddy and are placed in the conf directory of Apache Tomcat): hostname displays properly when typing command: hostname -f and/or typing: cat /etc/HOSTNAME on the linux server
