You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Peter Wallis <pw...@acm.org> on 2016/12/21 09:22:01 UTC

New to SSL - debugging tomcat

Hi all,
  I have tomcat 8.0.39 running on a raspberry pi (easy) and thought I'd try
setting it up to provide "skills" for the Amazon Echo Alexa service.  This
requires a url which "presents" either a signed certificate, or a
self-signed certificate.

Using fiirefox to check, I believe I got it presenting a self-signed
certificate but, as I have bought a domain name with a free certificate, I
thought I get that running before moving on to delivering skills.

A month later (this is not my day job) I'm still stuck.  sslchecker is the
most informative and says no certificates were found.  It does say "Server
Type: Apache-Coyote 1.1"

No messages on catalina.out; occasionally a message on xxx_access_log
saying "HEAD / HTTP/1.1" 200 -"  openssl verify just hangs; and Firefox
says secure connection failed.

The problem might be an issue with the CA; it might be my keystore; it
might be my tomcat settings.  I don't think it is the latter because the
self signed certificate seemed to work.  I don't think it is the CA or
keystore because I can a) verify the certificate chain with openssl and the
keystore tells me I have the certificates I think I have.

I have googled for getting tomcat to give some debug information but what
I've found so far has no effect.  Can someone point me to the official
how-to debug ssl issues on tomcat?

Thanks in advance,

Peter

Re: New to SSL - debugging tomcat

Posted by Peter Wallis <pw...@acm.org>.
using -Djavax.net.debug=all ...
what am I expecting to happen?

The only action I get is the line (which happens normally)

<ip address> - - <date and time> "HEAD / HTTP/1.1" 200 -

in my connector's access log.

On 21 December 2016 at 14:53, Peter Wallis <pw...@acm.org> wrote:

> Hi Hassan,
>  yes, but ... that says nothing about the key format (pem vs der?
> SHA1/SHA2) and there is an awful lot of actually conflicting instructions
> out there.  It took a while to realise that the private key is "in" the
> keystore, and that recreating the keystore means you have to start again
> with a new csr.  I have also seen that keytool will import pem files quite
> happily, so I guess these instructions are correct and not out of date as I
> originally thought.
>
> Given I seem to have a working keystore, and I have checked and rechecked
> my ssl tomcat configuration, and my setup works with http connections, I'd
> much prefer to debug what I have rather than start again.  Particularly as
> reconstructing the keystore will cost me, if not money, at least respect
> from my certificate provider support people.
>
> Debugging is apparently done using
>
> -Djavax.net.debug=all
> -Djavax.net.debug=ssl:handshake:data
>
> on the startup script (thanks Martin)
>
> - trying now...
>
> P
>
>
> On 21 December 2016 at 14:31, Hassan Schroeder <hassan.schroeder@gmail.com
> > wrote:
>
>> On Wed, Dec 21, 2016 at 1:22 AM, Peter Wallis <pw...@acm.org> wrote:
>>
>> > Can someone point me to the official how-to debug ssl issues on tomcat?
>>
>> Did you follow the steps in this documentation?
>>
>>   http://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html
>>
>> --
>> Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
>> twitter: @hassan
>> Consulting Availability : Silicon Valley or remote
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>

Re: New to SSL - debugging tomcat

Posted by Peter Wallis <pw...@acm.org>.
Hi Hassan,
 yes, but ... that says nothing about the key format (pem vs der?
SHA1/SHA2) and there is an awful lot of actually conflicting instructions
out there.  It took a while to realise that the private key is "in" the
keystore, and that recreating the keystore means you have to start again
with a new csr.  I have also seen that keytool will import pem files quite
happily, so I guess these instructions are correct and not out of date as I
originally thought.

Given I seem to have a working keystore, and I have checked and rechecked
my ssl tomcat configuration, and my setup works with http connections, I'd
much prefer to debug what I have rather than start again.  Particularly as
reconstructing the keystore will cost me, if not money, at least respect
from my certificate provider support people.

Debugging is apparently done using

-Djavax.net.debug=all
-Djavax.net.debug=ssl:handshake:data

on the startup script (thanks Martin)

- trying now...

P


On 21 December 2016 at 14:31, Hassan Schroeder <ha...@gmail.com>
wrote:

> On Wed, Dec 21, 2016 at 1:22 AM, Peter Wallis <pw...@acm.org> wrote:
>
> > Can someone point me to the official how-to debug ssl issues on tomcat?
>
> Did you follow the steps in this documentation?
>
>   http://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html
>
> --
> Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
> twitter: @hassan
> Consulting Availability : Silicon Valley or remote
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: New to SSL - debugging tomcat

Posted by Hassan Schroeder <ha...@gmail.com>.
On Wed, Dec 21, 2016 at 1:22 AM, Peter Wallis <pw...@acm.org> wrote:

> Can someone point me to the official how-to debug ssl issues on tomcat?

Did you follow the steps in this documentation?

  http://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html

-- 
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
twitter: @hassan
Consulting Availability : Silicon Valley or remote

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: New to SSL - debugging tomcat

Posted by Peter Wallis <pw...@acm.org>.
Thanks Chris,
 that seems to connect but sends no data back? The error is
 3074385544:error:1409E0E5:SSL ... :ssl handshake failure:s3_pkt.c:637
Returns:

CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1482460650
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
 I was trying to do something I thought was very standard.

 So, is this "an evolving standard" issue?  Is it something I have done
with keytool when producing a csr?  It is obviously not just openssl that
takes issue with TLS handshakes.  Is it just java in general? Or should I
be getting back to my certificate provider with a specific request? Change
provider?

P

On 22 December 2016 at 18:41, Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Peter,
>
> On 12/22/16 12:52 PM, Peter Wallis wrote:
> > Ahh! changed the server.xml entries to 8443 tried: openssl s_client
> > -connect 192.168.1.149:8443 and got: CONNECTED(00000003)
> > 3074541192:error:140790E5SSL routhines:SSL23_WRITE:ssl handshake
> > failure:s23_lib.c:177: --- no peer certificate available --- No
> > client certificate CA names sent --- SSL handshake has read 0 bytes
> > and written 295 bytes --- New, (NONE), Cipher is (ONE) Secure
> > Renegotiation IS NOT supported Compression: NONE Expansion: NONE
> > ---
> >
> > That might mean something (note I retyped it from a ssh connection
> > after a stiff drink so there may be typos)
>
>
> Perfect. The problem is that openssl s_clinent defaults to an SSLv2
> "hello" handshake and not a TLS handshake, which is more appropriate
> in this day and age.
>
> Try this:
>
> $ openssl s_client -tls1 -connect 192.168.1.149:8443
>
> - -chris
>
> > On 22 December 2016 at 16:27, Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> > Peter,
> >
> > On 12/22/16 11:03 AM, Peter Wallis wrote:
> >>>> Hi Christopher, re 443 on *nix; yes, set AUTHBIND='yes' in
> >>>> /etc/defaults/tomcat8
> >
> > Okay. Are you sure you've got that configured properly? Try
> > changing port 443 to 8443 in server.xml and bouncing Tomcat. Let's
> > try to solve one problem at a time.
> >
> >>>> re openssl s_client -connect on a different machine; it times
> >>>> out
> >>>>
> >>>> Did have a thought -- one that might not be obvious to you
> >>>> experts -- I am serving that page via No-IP dynamic dns.
> >>>> Their support people are "cagey" about whether this works or
> >>>> not (they don't answer the question and suggest I buy an
> >>>> upgraded service)  I believe people who know what they are
> >>>> doing just run their own dns using unbound?  If that makes no
> >>>> sense, please ignore; I don't know what I'm talking about but
> >>>> it seems we are looking for something I've done that is
> >>>> weird.
> >
> > Let's try this: what's the actual IP address of your pi?
> > 192.168.0.10 or somesuch?
> >
> > Change your port from 443 -> 8443 and then try this:
> >
> > $ openssl s_client -connect 192.168.0.10:8443
> >
> > If that connects and shows the cert, then your TLS configuration
> > is correct. It will complain about the hostname (IP address) not
> > matching the cert's CN, but that's okay).
> >
> > Since you have lots of moving parts, let's find out what's working
> > first and then fix whatever problems remain.
> >
> > -chris
> >
> >>>> On 22 December 2016 at 15:38, Christopher Schultz <
> >>>> chris@christopherschultz.net> wrote:
> >>>>
> >>>> Peter,
> >>>>
> >>>> On 12/22/16 2:43 AM, Peter Wallis wrote:
> >>>>>>> Hi Christopher, so it seems I have done something
> >>>>>>> exceptional :-) Thanks for taking a look...
> >>>>>>>
> >>>>>>> <Connector port="443"
> >>>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
> >>>>>>> maxThreads="150" SSLEnabled="true" scheme="https"
> >>>>>>> secure="true" keystoreFile="/home/peter/.keystore"
> >>>>>>> alias="tomcat" keystorePass="changeit"
> >>>>>>> clientAuth="false" sslProtocol="TLS" />
> >>>>
> >>>> This looks fine except for one thing: you are using port 443
> >>>> on a *NIX system which requires you to either run as root
> >>>> (bad) or make other arrangements. Have you made such
> >>>> arrangements?
> >>>>
> >>>>>>> Keystore type: JKS Keystore provider: SUN
> >>>>>>>
> >>>>>>> Your keystore contains 2 entries
> >>>>>>>
> >>>>>>> Alias name: gandi Creation date: 21-Dec-2016 Entry
> >>>>>>> type: trustedCertEntry
> >>>>
> >>>> Okay, that's your CA.
> >>>>
> >>>>>>> Alias name: tomcat Creation date: 21-Dec-2016 Entry
> >>>>>>> type: trustedCertEntry
> >>>>
> >>>> Okay, that's presumably your server's cert.
> >>>>
> >>>>>>> Owner: CN=alexa.proseco.co.uk, OU=Gandi Standard SSL,
> >>>>>>> OU=Domain Control Validated
> >>>>
> >>>> If that's your site name (alexa.proseco.co.uk) this looks
> >>>> good.
> >>>>
> >>>> What happens if you do this from the outside (e.g. not on the
> >>>> pi itself) :
> >>>>
> >>>> $ openssl s_client -connect alexa.proseco.co.uk:443
> >>>>
> >>>> -chris
> >>>>>
> >>>>> ------------------------------------------------------------------
> - ---
> >>>>>
> >>>>>
> >
> >>>>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>> For additional commands, e-mail:
> >>>>> users-help@tomcat.apache.org
> >>>>>
> >>>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYXB5uAAoJEBzwKT+lPKRY+ZYP/1faZ00ji63QXmcx4aKC/6IM
> F++ivxg+QaDivCcPmQn4oYKYXyy/Yhq0eEvj7EyyQ0OVEEqJv5f/WwpW1uOEmz5E
> Lx8KI+ZNwQiDRy2VqSUkhUV09sodDVanX2BCpY0VGfy8fbtRHJfZbcTf3xUH+j/D
> ofeG7NbuWIrD8NRLvL4wPRv2jDhkLMPQ5tw6JcghLFkMS6/CzOELS4UpaMlI1Iel
> nYBFlFpL8e+c0r6OU+jiwBMnn1sOuqe96mxN8gj9O7QJ0wlXZocoTOf/AptPWI08
> NlZ5L1R2jfKT7ZInMSDVw4PNTYLUMiZV24YYCccS3X4qR+tCPWrahU1yb4npyuOI
> srWRJBMNXyeedIo6UO8bVHdnZGSs3NsmSnXAXuBAGtpuAqW+Mw6R9YPvQ4OC5eJR
> bva7AlJ19n8qJQRItWZPTWLOZKlBMz/BOqV1TedVZDjiZonHLhMwJTBiRipKH4ay
> tu3W9sa0rYGrOIDH5spwdve3AXqwRDlUccs9VtGhxRAalpwWSP+nZHMgyUGYm8sV
> lYdU6tMXJIPGGzeBPh3POPKTylG6WCYPm7MHW55TIEO0woUKyPdZGjSDraB6stKU
> +anWglr5snrcdFcmiCdKZikpz3vdDBc9vpimMhEWqDmjhs5M1RqlHnwfdPGoElJF
> N40qXw5NkfyZZ+/jQrds
> =ljgn
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: New to SSL - debugging tomcat

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Peter,

On 12/22/16 12:52 PM, Peter Wallis wrote:
> Ahh! changed the server.xml entries to 8443 tried: openssl s_client
> -connect 192.168.1.149:8443 and got: CONNECTED(00000003) 
> 3074541192:error:140790E5SSL routhines:SSL23_WRITE:ssl handshake 
> failure:s23_lib.c:177: --- no peer certificate available --- No
> client certificate CA names sent --- SSL handshake has read 0 bytes
> and written 295 bytes --- New, (NONE), Cipher is (ONE) Secure
> Renegotiation IS NOT supported Compression: NONE Expansion: NONE 
> ---
> 
> That might mean something (note I retyped it from a ssh connection
> after a stiff drink so there may be typos)


Perfect. The problem is that openssl s_clinent defaults to an SSLv2
"hello" handshake and not a TLS handshake, which is more appropriate
in this day and age.

Try this:

$ openssl s_client -tls1 -connect 192.168.1.149:8443

- -chris

> On 22 December 2016 at 16:27, Christopher Schultz < 
> chris@christopherschultz.net> wrote:
> 
> Peter,
> 
> On 12/22/16 11:03 AM, Peter Wallis wrote:
>>>> Hi Christopher, re 443 on *nix; yes, set AUTHBIND='yes' in 
>>>> /etc/defaults/tomcat8
> 
> Okay. Are you sure you've got that configured properly? Try
> changing port 443 to 8443 in server.xml and bouncing Tomcat. Let's
> try to solve one problem at a time.
> 
>>>> re openssl s_client -connect on a different machine; it times
>>>> out
>>>> 
>>>> Did have a thought -- one that might not be obvious to you
>>>> experts -- I am serving that page via No-IP dynamic dns.
>>>> Their support people are "cagey" about whether this works or
>>>> not (they don't answer the question and suggest I buy an
>>>> upgraded service)  I believe people who know what they are
>>>> doing just run their own dns using unbound?  If that makes no
>>>> sense, please ignore; I don't know what I'm talking about but
>>>> it seems we are looking for something I've done that is
>>>> weird.
> 
> Let's try this: what's the actual IP address of your pi?
> 192.168.0.10 or somesuch?
> 
> Change your port from 443 -> 8443 and then try this:
> 
> $ openssl s_client -connect 192.168.0.10:8443
> 
> If that connects and shows the cert, then your TLS configuration
> is correct. It will complain about the hostname (IP address) not
> matching the cert's CN, but that's okay).
> 
> Since you have lots of moving parts, let's find out what's working 
> first and then fix whatever problems remain.
> 
> -chris
> 
>>>> On 22 December 2016 at 15:38, Christopher Schultz < 
>>>> chris@christopherschultz.net> wrote:
>>>> 
>>>> Peter,
>>>> 
>>>> On 12/22/16 2:43 AM, Peter Wallis wrote:
>>>>>>> Hi Christopher, so it seems I have done something
>>>>>>> exceptional :-) Thanks for taking a look...
>>>>>>> 
>>>>>>> <Connector port="443" 
>>>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol" 
>>>>>>> maxThreads="150" SSLEnabled="true" scheme="https" 
>>>>>>> secure="true" keystoreFile="/home/peter/.keystore" 
>>>>>>> alias="tomcat" keystorePass="changeit"
>>>>>>> clientAuth="false" sslProtocol="TLS" />
>>>> 
>>>> This looks fine except for one thing: you are using port 443
>>>> on a *NIX system which requires you to either run as root
>>>> (bad) or make other arrangements. Have you made such
>>>> arrangements?
>>>> 
>>>>>>> Keystore type: JKS Keystore provider: SUN
>>>>>>> 
>>>>>>> Your keystore contains 2 entries
>>>>>>> 
>>>>>>> Alias name: gandi Creation date: 21-Dec-2016 Entry
>>>>>>> type: trustedCertEntry
>>>> 
>>>> Okay, that's your CA.
>>>> 
>>>>>>> Alias name: tomcat Creation date: 21-Dec-2016 Entry
>>>>>>> type: trustedCertEntry
>>>> 
>>>> Okay, that's presumably your server's cert.
>>>> 
>>>>>>> Owner: CN=alexa.proseco.co.uk, OU=Gandi Standard SSL, 
>>>>>>> OU=Domain Control Validated
>>>> 
>>>> If that's your site name (alexa.proseco.co.uk) this looks
>>>> good.
>>>> 
>>>> What happens if you do this from the outside (e.g. not on the
>>>> pi itself) :
>>>> 
>>>> $ openssl s_client -connect alexa.proseco.co.uk:443
>>>> 
>>>> -chris
>>>>> 
>>>>> ------------------------------------------------------------------
- ---
>>>>>
>>>>>
>
>>>>> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail:
>>>>> users-help@tomcat.apache.org
>>>>> 
>>>>> 
>>>> 
>> 
>> ---------------------------------------------------------------------
>>
>> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>> 
>> 
> 
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYXB5uAAoJEBzwKT+lPKRY+ZYP/1faZ00ji63QXmcx4aKC/6IM
F++ivxg+QaDivCcPmQn4oYKYXyy/Yhq0eEvj7EyyQ0OVEEqJv5f/WwpW1uOEmz5E
Lx8KI+ZNwQiDRy2VqSUkhUV09sodDVanX2BCpY0VGfy8fbtRHJfZbcTf3xUH+j/D
ofeG7NbuWIrD8NRLvL4wPRv2jDhkLMPQ5tw6JcghLFkMS6/CzOELS4UpaMlI1Iel
nYBFlFpL8e+c0r6OU+jiwBMnn1sOuqe96mxN8gj9O7QJ0wlXZocoTOf/AptPWI08
NlZ5L1R2jfKT7ZInMSDVw4PNTYLUMiZV24YYCccS3X4qR+tCPWrahU1yb4npyuOI
srWRJBMNXyeedIo6UO8bVHdnZGSs3NsmSnXAXuBAGtpuAqW+Mw6R9YPvQ4OC5eJR
bva7AlJ19n8qJQRItWZPTWLOZKlBMz/BOqV1TedVZDjiZonHLhMwJTBiRipKH4ay
tu3W9sa0rYGrOIDH5spwdve3AXqwRDlUccs9VtGhxRAalpwWSP+nZHMgyUGYm8sV
lYdU6tMXJIPGGzeBPh3POPKTylG6WCYPm7MHW55TIEO0woUKyPdZGjSDraB6stKU
+anWglr5snrcdFcmiCdKZikpz3vdDBc9vpimMhEWqDmjhs5M1RqlHnwfdPGoElJF
N40qXw5NkfyZZ+/jQrds
=ljgn
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: New to SSL - debugging tomcat

Posted by Peter Wallis <pw...@acm.org>.
Ahh!
changed the server.xml entries to 8443
tried:
  openssl s_client -connect 192.168.1.149:8443
and got:
  CONNECTED(00000003)
3074541192:error:140790E5SSL routhines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 295 bytes
---
New, (NONE), Cipher is (ONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

That might mean something (note I retyped it from a ssh connection after a
stiff drink so there may be typos)

P

On 22 December 2016 at 16:27, Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Peter,
>
> On 12/22/16 11:03 AM, Peter Wallis wrote:
> > Hi Christopher, re 443 on *nix; yes, set AUTHBIND='yes' in
> > /etc/defaults/tomcat8
>
> Okay. Are you sure you've got that configured properly? Try changing
> port 443 to 8443 in server.xml and bouncing Tomcat. Let's try to solve
> one problem at a time.
>
> > re openssl s_client -connect on a different machine; it times out
> >
> > Did have a thought -- one that might not be obvious to you experts
> > -- I am serving that page via No-IP dynamic dns.  Their support
> > people are "cagey" about whether this works or not (they don't
> > answer the question and suggest I buy an upgraded service)  I
> > believe people who know what they are doing just run their own dns
> > using unbound?  If that makes no sense, please ignore; I don't know
> > what I'm talking about but it seems we are looking for something
> > I've done that is weird.
>
> Let's try this: what's the actual IP address of your pi? 192.168.0.10
> or somesuch?
>
> Change your port from 443 -> 8443 and then try this:
>
> $ openssl s_client -connect 192.168.0.10:8443
>
> If that connects and shows the cert, then your TLS configuration is
> correct. It will complain about the hostname (IP address) not matching
> the cert's CN, but that's okay).
>
> Since you have lots of moving parts, let's find out what's working
> first and then fix whatever problems remain.
>
> - -chris
>
> > On 22 December 2016 at 15:38, Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> > Peter,
> >
> > On 12/22/16 2:43 AM, Peter Wallis wrote:
> >>>> Hi Christopher, so it seems I have done something exceptional
> >>>> :-) Thanks for taking a look...
> >>>>
> >>>> <Connector port="443"
> >>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
> >>>> maxThreads="150" SSLEnabled="true" scheme="https"
> >>>> secure="true" keystoreFile="/home/peter/.keystore"
> >>>> alias="tomcat" keystorePass="changeit" clientAuth="false"
> >>>> sslProtocol="TLS" />
> >
> > This looks fine except for one thing: you are using port 443 on a
> > *NIX system which requires you to either run as root (bad) or make
> > other arrangements. Have you made such arrangements?
> >
> >>>> Keystore type: JKS Keystore provider: SUN
> >>>>
> >>>> Your keystore contains 2 entries
> >>>>
> >>>> Alias name: gandi Creation date: 21-Dec-2016 Entry type:
> >>>> trustedCertEntry
> >
> > Okay, that's your CA.
> >
> >>>> Alias name: tomcat Creation date: 21-Dec-2016 Entry type:
> >>>> trustedCertEntry
> >
> > Okay, that's presumably your server's cert.
> >
> >>>> Owner: CN=alexa.proseco.co.uk, OU=Gandi Standard SSL,
> >>>> OU=Domain Control Validated
> >
> > If that's your site name (alexa.proseco.co.uk) this looks good.
> >
> > What happens if you do this from the outside (e.g. not on the pi
> > itself) :
> >
> > $ openssl s_client -connect alexa.proseco.co.uk:443
> >
> > -chris
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYW/7iAAoJEBzwKT+lPKRYrG8P/RvLPGw1Xs9nckpTnrDWO8DA
> 1Df5CIEign1cbPTiO1MsMqUG0ZttsntWBCDO9dXUZ4COgjjQlj0svMQkhMqYFAeS
> GplutOm2ogcSlmh0asmmQlhcca3KYf4JCxe6I2MAO7jvgzaqP5YQBkP8yXK+RRtP
> hkhvqRfBJxChNtZ9L40HoFqUputXe+8aGTSoIUXVmi66xzj3sdn7SHJ3ktVE2ewp
> 1q9paiMZeR21l+NsgAdqm+aZO02DMvhgDXHCcmD/CHdcNETO0VplZk2x97QKJcSn
> dXny45c+uuGQxMIEcfokMWDVl0WqYQjBUaWdh7TvX45Ovbp5QZVlVDh2dinWEFVV
> 2wsGrODf22BFccvEvrZhVdT4G1efkpiHn2F4z0TO0DCjnYnvmMLJ7RRAjxKlDU9c
> xdi124ByqoBgF42iS5BN1tlM9pzfefsHlqf0kR/zNxcqtEwLejm3/B/2CKTm2Lvw
> EM0CBzYrz5WOybcYdlpCwHM9KEZBnO3Vh3NX0sdWc7OMFmmaofySuQEpnpQWP71z
> AMGCRdvPDNV1r4WP0gu8R4piOMWf2I234mi89g4Z2ebJ8Ymi+jk7dKTrl6BO/l+Y
> NkKPjURv7pk1pXm2qGkB7sQDaTTKQLvBu86c9QCzrXP1zN727JTTrVFUfu0BIHfG
> /kMLCZzFz938B9ZwBlER
> =GA0t
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: New to SSL - debugging tomcat

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Peter,

On 12/22/16 11:03 AM, Peter Wallis wrote:
> Hi Christopher, re 443 on *nix; yes, set AUTHBIND='yes' in
> /etc/defaults/tomcat8

Okay. Are you sure you've got that configured properly? Try changing
port 443 to 8443 in server.xml and bouncing Tomcat. Let's try to solve
one problem at a time.

> re openssl s_client -connect on a different machine; it times out
> 
> Did have a thought -- one that might not be obvious to you experts
> -- I am serving that page via No-IP dynamic dns.  Their support
> people are "cagey" about whether this works or not (they don't
> answer the question and suggest I buy an upgraded service)  I
> believe people who know what they are doing just run their own dns
> using unbound?  If that makes no sense, please ignore; I don't know
> what I'm talking about but it seems we are looking for something
> I've done that is weird.

Let's try this: what's the actual IP address of your pi? 192.168.0.10
or somesuch?

Change your port from 443 -> 8443 and then try this:

$ openssl s_client -connect 192.168.0.10:8443

If that connects and shows the cert, then your TLS configuration is
correct. It will complain about the hostname (IP address) not matching
the cert's CN, but that's okay).

Since you have lots of moving parts, let's find out what's working
first and then fix whatever problems remain.

- -chris

> On 22 December 2016 at 15:38, Christopher Schultz < 
> chris@christopherschultz.net> wrote:
> 
> Peter,
> 
> On 12/22/16 2:43 AM, Peter Wallis wrote:
>>>> Hi Christopher, so it seems I have done something exceptional
>>>> :-) Thanks for taking a look...
>>>> 
>>>> <Connector port="443" 
>>>> protocol="org.apache.coyote.http11.Http11NioProtocol" 
>>>> maxThreads="150" SSLEnabled="true" scheme="https"
>>>> secure="true" keystoreFile="/home/peter/.keystore"
>>>> alias="tomcat" keystorePass="changeit" clientAuth="false"
>>>> sslProtocol="TLS" />
> 
> This looks fine except for one thing: you are using port 443 on a
> *NIX system which requires you to either run as root (bad) or make
> other arrangements. Have you made such arrangements?
> 
>>>> Keystore type: JKS Keystore provider: SUN
>>>> 
>>>> Your keystore contains 2 entries
>>>> 
>>>> Alias name: gandi Creation date: 21-Dec-2016 Entry type: 
>>>> trustedCertEntry
> 
> Okay, that's your CA.
> 
>>>> Alias name: tomcat Creation date: 21-Dec-2016 Entry type: 
>>>> trustedCertEntry
> 
> Okay, that's presumably your server's cert.
> 
>>>> Owner: CN=alexa.proseco.co.uk, OU=Gandi Standard SSL,
>>>> OU=Domain Control Validated
> 
> If that's your site name (alexa.proseco.co.uk) this looks good.
> 
> What happens if you do this from the outside (e.g. not on the pi
> itself) :
> 
> $ openssl s_client -connect alexa.proseco.co.uk:443
> 
> -chris
>> 
>> ---------------------------------------------------------------------
>>
>> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>> 
>> 
> 
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYW/7iAAoJEBzwKT+lPKRYrG8P/RvLPGw1Xs9nckpTnrDWO8DA
1Df5CIEign1cbPTiO1MsMqUG0ZttsntWBCDO9dXUZ4COgjjQlj0svMQkhMqYFAeS
GplutOm2ogcSlmh0asmmQlhcca3KYf4JCxe6I2MAO7jvgzaqP5YQBkP8yXK+RRtP
hkhvqRfBJxChNtZ9L40HoFqUputXe+8aGTSoIUXVmi66xzj3sdn7SHJ3ktVE2ewp
1q9paiMZeR21l+NsgAdqm+aZO02DMvhgDXHCcmD/CHdcNETO0VplZk2x97QKJcSn
dXny45c+uuGQxMIEcfokMWDVl0WqYQjBUaWdh7TvX45Ovbp5QZVlVDh2dinWEFVV
2wsGrODf22BFccvEvrZhVdT4G1efkpiHn2F4z0TO0DCjnYnvmMLJ7RRAjxKlDU9c
xdi124ByqoBgF42iS5BN1tlM9pzfefsHlqf0kR/zNxcqtEwLejm3/B/2CKTm2Lvw
EM0CBzYrz5WOybcYdlpCwHM9KEZBnO3Vh3NX0sdWc7OMFmmaofySuQEpnpQWP71z
AMGCRdvPDNV1r4WP0gu8R4piOMWf2I234mi89g4Z2ebJ8Ymi+jk7dKTrl6BO/l+Y
NkKPjURv7pk1pXm2qGkB7sQDaTTKQLvBu86c9QCzrXP1zN727JTTrVFUfu0BIHfG
/kMLCZzFz938B9ZwBlER
=GA0t
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: New to SSL - debugging tomcat

Posted by Peter Wallis <pw...@acm.org>.
Hi Christopher,
 re 443 on *nix; yes, set AUTHBIND='yes' in /etc/defaults/tomcat8
 re openssl s_client -connect on a different machine; it times out

Did have a thought -- one that might not be obvious to you experts -- I am
serving that page via No-IP dynamic dns.  Their support people are "cagey"
about whether this works or not (they don't answer the question and suggest
I buy an upgraded service)  I believe people who know what they are doing
just run their own dns using unbound?  If that makes no sense, please
ignore; I don't know what I'm talking about but it seems we are looking for
something I've done that is weird.

P

On 22 December 2016 at 15:38, Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Peter,
>
> On 12/22/16 2:43 AM, Peter Wallis wrote:
> > Hi Christopher, so it seems I have done something exceptional :-)
> > Thanks for taking a look...
> >
> > <Connector port="443"
> > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
> > keystoreFile="/home/peter/.keystore" alias="tomcat"
> > keystorePass="changeit" clientAuth="false" sslProtocol="TLS" />
>
> This looks fine except for one thing: you are using port 443 on a *NIX
> system which requires you to either run as root (bad) or make other
> arrangements. Have you made such arrangements?
>
> > Keystore type: JKS Keystore provider: SUN
> >
> > Your keystore contains 2 entries
> >
> > Alias name: gandi Creation date: 21-Dec-2016 Entry type:
> > trustedCertEntry
>
> Okay, that's your CA.
>
> > Alias name: tomcat Creation date: 21-Dec-2016 Entry type:
> > trustedCertEntry
>
> Okay, that's presumably your server's cert.
>
> > Owner: CN=alexa.proseco.co.uk, OU=Gandi Standard SSL, OU=Domain
> > Control Validated
>
> If that's your site name (alexa.proseco.co.uk) this looks good.
>
> What happens if you do this from the outside (e.g. not on the pi itself)
> :
>
> $ openssl s_client -connect alexa.proseco.co.uk:443
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYW/NwAAoJEBzwKT+lPKRYbf0P/3LawCFJivA7997fbYvFCw5h
> A9p1aWXNYMzRiaGcltoYk+fZVtTQ0Ve5mBtSDV8nN+mulEt2mPD6nxbvhjw1H24z
> pononiduIpv30QduqlXQeczUtdptjNMzsDP+zg1HdnEF45xSmQl/egn3/QCBqMIH
> hYNmxgxJpipDlruv5sNhM/0BRF2jvmG3mqByX/ayguCP7eC16nXMzYriVMauUj+L
> QVZHlitdeLu8ZcHMxKz0B60gho64Hivlf/HlEiEINtyq5jYgN16dLNRzuMlZ34cd
> UAdOtT28eA4hIfK4KQZrpO/iSNn4gaKV7wBH8FswvgqJdLBT/ucKuzWOmfMY0cBx
> vLtBK6y1XFasfkGOkWoS8I2ViomygUgWDTIsFSmikaMgqJg2joxatLx50rT6oXyo
> KM4y074J8CSwxP+/UiwugRGCfiDfRHDZErEWXTpQmcsHrrSwJWlqCk6l/gUscB/X
> XM3XLKFK+8JUXnsYHYe9lylrrfHKUm8SgNVkQsBF7b7RHtKh1kWJjD2/xMFb3C0P
> FuZnNdFc22MEaDnisp5ofqDAYNTDvJLkVn+2ererNmeWdrRq8Cf7/X4QrLeTlMh/
> 7GcRGq0C9/2ZRc+1pyFhjfef6MwZ1wceqiquBZYokdyoPHdQ82VAyPg1ffVRfskl
> 1TsRsxA+hHeIkgCE161B
> =yhHl
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: New to SSL - debugging tomcat

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Peter,

On 12/22/16 2:43 AM, Peter Wallis wrote:
> Hi Christopher, so it seems I have done something exceptional :-)
> Thanks for taking a look...
> 
> <Connector port="443" 
> protocol="org.apache.coyote.http11.Http11NioProtocol" 
> maxThreads="150" SSLEnabled="true" scheme="https" secure="true" 
> keystoreFile="/home/peter/.keystore" alias="tomcat" 
> keystorePass="changeit" clientAuth="false" sslProtocol="TLS" />

This looks fine except for one thing: you are using port 443 on a *NIX
system which requires you to either run as root (bad) or make other
arrangements. Have you made such arrangements?

> Keystore type: JKS Keystore provider: SUN
> 
> Your keystore contains 2 entries
> 
> Alias name: gandi Creation date: 21-Dec-2016 Entry type:
> trustedCertEntry

Okay, that's your CA.

> Alias name: tomcat Creation date: 21-Dec-2016 Entry type:
> trustedCertEntry

Okay, that's presumably your server's cert.

> Owner: CN=alexa.proseco.co.uk, OU=Gandi Standard SSL, OU=Domain
> Control Validated

If that's your site name (alexa.proseco.co.uk) this looks good.

What happens if you do this from the outside (e.g. not on the pi itself)
:

$ openssl s_client -connect alexa.proseco.co.uk:443

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYW/NwAAoJEBzwKT+lPKRYbf0P/3LawCFJivA7997fbYvFCw5h
A9p1aWXNYMzRiaGcltoYk+fZVtTQ0Ve5mBtSDV8nN+mulEt2mPD6nxbvhjw1H24z
pononiduIpv30QduqlXQeczUtdptjNMzsDP+zg1HdnEF45xSmQl/egn3/QCBqMIH
hYNmxgxJpipDlruv5sNhM/0BRF2jvmG3mqByX/ayguCP7eC16nXMzYriVMauUj+L
QVZHlitdeLu8ZcHMxKz0B60gho64Hivlf/HlEiEINtyq5jYgN16dLNRzuMlZ34cd
UAdOtT28eA4hIfK4KQZrpO/iSNn4gaKV7wBH8FswvgqJdLBT/ucKuzWOmfMY0cBx
vLtBK6y1XFasfkGOkWoS8I2ViomygUgWDTIsFSmikaMgqJg2joxatLx50rT6oXyo
KM4y074J8CSwxP+/UiwugRGCfiDfRHDZErEWXTpQmcsHrrSwJWlqCk6l/gUscB/X
XM3XLKFK+8JUXnsYHYe9lylrrfHKUm8SgNVkQsBF7b7RHtKh1kWJjD2/xMFb3C0P
FuZnNdFc22MEaDnisp5ofqDAYNTDvJLkVn+2ererNmeWdrRq8Cf7/X4QrLeTlMh/
7GcRGq0C9/2ZRc+1pyFhjfef6MwZ1wceqiquBZYokdyoPHdQ82VAyPg1ffVRfskl
1TsRsxA+hHeIkgCE161B
=yhHl
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: New to SSL - debugging tomcat

Posted by Peter Wallis <pw...@acm.org>.
Hi Christopher,
 so it seems I have done something exceptional :-)  Thanks for taking a
look...

    <Connector port="443"
protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true" scheme="https"
secure="true"
           keystoreFile="/home/peter/.keystore" alias="tomcat"
           keystorePass="changeit"
               clientAuth="false" sslProtocol="TLS" />

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

Alias name: gandi
Creation date: 21-Dec-2016
Entry type: trustedCertEntry

Owner: CN=Gandi Standard SSL CA 2, O=Gandi, L=Paris, ST=Paris, C=FR
Issuer: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network,
L=Jersey City, ST=New Jersey, C=US
Serial number: 5e4dc3b9438ab3b8597cba6a19850e3
Valid from: Fri Sep 12 00:00:00 UTC 2014 until: Wed Sep 11 23:59:59 UTC 2024
Certificate fingerprints:
     MD5:  1A:9A:69:A8:1F:6D:A9:2D:87:F7:69:4E:16:D8:B8:79
     SHA1: 24:71:06:A4:05:B2:88:A4:6E:70:A0:26:27:17:16:2D:09:03:E7:34
     SHA256:
B9:F2:16:43:23:63:8D:CE:0B:92:21:8B:43:C4:1C:1B:2B:26:96:38:93:29:DB:19:F5:CF:7A:D4:9B:5C:B3:72
     Signature algorithm name: SHA384withRSA
     Version: 3

Extensions:

#1: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
AuthorityInfoAccess [
  [
   accessMethod: caIssuers
   accessLocation: URIName:
http://crt.usertrust.com/USERTrustRSAAddTrustCA.crt
,
   accessMethod: ocsp
   accessLocation: URIName: http://ocsp.usertrust.com
]
]

#2: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 53 79 BF 5A AA 2B 4A CF   54 80 E1 D8 9B C0 9D F2  Sy.Z.+J.T.......
0010: B2 03 66 CB                                        ..f.
]
]

#3: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:0
]

#4: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
  [DistributionPoint:
     [URIName:
http://crl.usertrust.com/USERTrustRSACertificationAuthority.crl]
]]

#5: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
  [CertificatePolicyId: [1.3.6.1.4.1.6449.1.2.2.26]
[]  ]
  [CertificatePolicyId: [2.23.140.1.2.1]
[]  ]
]

#6: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
  serverAuth
  clientAuth
]

#7: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_CertSign
  Crl_Sign
]

#8: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: B3 90 A7 D8 C9 AF 4E CD   61 3C 9F 7C AD 5D 7F 41  ......N.a<...].A
0010: FD 69 30 EA                                        .i0.
]
]



*******************************************
*******************************************


Alias name: tomcat
Creation date: 21-Dec-2016
Entry type: trustedCertEntry

Owner: CN=alexa.proseco.co.uk, OU=Gandi Standard SSL, OU=Domain Control
Validated
Issuer: CN=Gandi Standard SSL CA 2, O=Gandi, L=Paris, ST=Paris, C=FR
Serial number: 722e058c0d81e1089658a9934163c58a
Valid from: Fri Dec 16 00:00:00 UTC 2016 until: Sat Dec 16 23:59:59 UTC 2017
Certificate fingerprints:
     MD5:  CA:36:D1:ED:4E:EC:69:91:D8:92:75:71:86:01:A9:6E
     SHA1: F3:08:57:19:0E:2C:58:2A:55:B7:71:E3:00:30:D4:84:3F:BA:98:E7
     SHA256:
AE:7C:12:C5:C0:20:04:A0:A8:77:AF:E8:67:86:0F:83:30:25:D8:83:C5:A7:88:8F:6A:F4:46:B3:0D:ED:BE:6A
     Signature algorithm name: SHA256withRSA
     Version: 3

Extensions:

#1: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
AuthorityInfoAccess [
  [
   accessMethod: caIssuers
   accessLocation: URIName: http://crt.usertrust.com/GandiStandardSSLCA2.crt
,
   accessMethod: ocsp
   accessLocation: URIName: http://ocsp.usertrust.com
]
]

#2: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: B3 90 A7 D8 C9 AF 4E CD   61 3C 9F 7C AD 5D 7F 41  ......N.a<...].A
0010: FD 69 30 EA                                        .i0.
]
]

#3: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:false
  PathLen: undefined
]

#4: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
  [DistributionPoint:
     [URIName: http://crl.usertrust.com/GandiStandardSSLCA2.crl]
]]

#5: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
  [CertificatePolicyId: [1.3.6.1.4.1.6449.1.2.2.26]
[PolicyQualifierInfo: [
  qualifierID: 1.3.6.1.5.5.7.2.1
  qualifier: 0000: 16 19 68 74 74 70 73 3A   2F 2F 63 70 73 2E 75 73  ..
https://cps.us
0010: 65 72 74 72 75 73 74 2E   63 6F 6D                 ertrust.com

]]  ]
  [CertificatePolicyId: [2.23.140.1.2.1]
[]  ]
]

#6: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
  serverAuth
  clientAuth
]

#7: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_Encipherment
]

#8: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
  DNSName: alexa.proseco.co.uk
  DNSName: www.alexa.proseco.co.uk
]

#9: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: BF 52 0C 03 DD 23 55 BA   3F EB DD F3 C5 56 FE A0  .R...#U.?....V..
0010: 3B 0F F1 E8                                        ;...
]
]



*******************************************
*******************************************




On 21 December 2016 at 21:17, Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Peter,
>
> On 12/21/16 4:22 AM, Peter Wallis wrote:
> > Hi all, I have tomcat 8.0.39 running on a raspberry pi (easy) and
> > thought I'd try setting it up to provide "skills" for the Amazon
> > Echo Alexa service.  This requires a url which "presents" either a
> > signed certificate, or a self-signed certificate.
> >
> > Using fiirefox to check, I believe I got it presenting a
> > self-signed certificate but, as I have bought a domain name with a
> > free certificate, I thought I get that running before moving on to
> > delivering skills.
>
> Sounds good.
>
> > A month later (this is not my day job) I'm still stuck.  sslchecker
> > is the most informative and says no certificates were found.  It
> > does say "Server Type: Apache-Coyote 1.1"
>
> Okay, so you can make a connection: that's good :)
>
> > No messages on catalina.out; occasionally a message on
> > xxx_access_log saying "HEAD / HTTP/1.1" 200 -"  openssl verify just
> > hangs; and Firefox says secure connection failed.
>
> Okay, so we have a place to start. First of all, "openssl verify"
> isn't what you want to use to connect. Instead, you want "openssl
> s_client".
>
> Can you post your <Connector> configuration?
>
> > The problem might be an issue with the CA; it might be my keystore;
> > it might be my tomcat settings.  I don't think it is the latter
> > because the self signed certificate seemed to work.  I don't think
> > it is the CA or keystore because I can a) verify the certificate
> > chain with openssl and the keystore tells me I have the
> > certificates I think I have.
>
> What matters is what the server (Tomcat) is presenting to the client,
> not what's actually in the keystore (though usually they are very
> closely related).
>
> > I have googled for getting tomcat to give some debug information
> > but what I've found so far has no effect.  Can someone point me to
> > the official how-to debug ssl issues on tomcat?
>
> There isn't really an official "Tomcat" TLS debugging how-to, because
> they are all pretty much the same. Most of the confusion occurs in one
> specific place: key/cert management (key, csr, cert, chain, etc.)
> because if you don't understand it, it's easy to get lost.
>
> Along with posting your <Connector> configuration, can you post the
> output of this command:
>
> $ keytool -list -verbose -keystore [keystorename]
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYWvFWAAoJEBzwKT+lPKRYqdsQAKZxQQz1PF5VH88y1IDRLq2+
> qegBtNOF+oTTzueeWveFnUS13stvYBpxNC0jU8GHt1jsbSs13hlxUby7trstAhev
> nmQCvd31g+8i7VQOKpUSAyCBHJBrZn9FAhcJDrVdZZP7SInCp4KzmyNnUUEAIgQs
> hsqm3LaquabergPUwidXMlBD7P6mZ+74GorGoX06J6/ivaP6RRrxG1OVDeYzH/mZ
> ai8x9Q/UOtaFJOrb7tK6JJRNQaiSb7Pryozrdu/81Gi9pDALToden1LWlqa1nvHF
> xBpbM1lTEs0W24gACZtaGv2IJsNoFgJ76/S9nLH5NOMDZBNPnpfhoAQrOUH9YHIt
> hme4kltU69saE10hkvqrsvVQ5XplXwD4F3q8XnE2JHYv0bTl8cg7fL3yvtPPXUCC
> pIe1QioEAu+nKVrpV7KvPfYGhAsxJ2kVcho/bv+sANEWyMEqqfRR/zCnOU5Ge7OE
> e7OrQylXVcXQazfV0Hxd62CYCKW0lhx8Vm60q9sr4QcsYr21QRKr6NUWvC8PQTci
> XEpyKYEJ4E8CMxpaOqGl9khpQzkCnSxhRPg1nrlsWc/dDML8BnEuwF3xAR4pObP3
> BRrMEhldoN/px/TPqTTnNxh9qr2A2Y+K3x/Ptg1VxGXiwFbEcTYVSh5rKaoASsLz
> o3RRxtRPiC1NrAlTK2Bc
> =AKTz
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: New to SSL - debugging tomcat

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Peter,

On 12/21/16 4:22 AM, Peter Wallis wrote:
> Hi all, I have tomcat 8.0.39 running on a raspberry pi (easy) and
> thought I'd try setting it up to provide "skills" for the Amazon
> Echo Alexa service.  This requires a url which "presents" either a
> signed certificate, or a self-signed certificate.
> 
> Using fiirefox to check, I believe I got it presenting a
> self-signed certificate but, as I have bought a domain name with a
> free certificate, I thought I get that running before moving on to
> delivering skills.

Sounds good.

> A month later (this is not my day job) I'm still stuck.  sslchecker
> is the most informative and says no certificates were found.  It
> does say "Server Type: Apache-Coyote 1.1"

Okay, so you can make a connection: that's good :)

> No messages on catalina.out; occasionally a message on
> xxx_access_log saying "HEAD / HTTP/1.1" 200 -"  openssl verify just
> hangs; and Firefox says secure connection failed.

Okay, so we have a place to start. First of all, "openssl verify"
isn't what you want to use to connect. Instead, you want "openssl
s_client".

Can you post your <Connector> configuration?

> The problem might be an issue with the CA; it might be my keystore;
> it might be my tomcat settings.  I don't think it is the latter
> because the self signed certificate seemed to work.  I don't think
> it is the CA or keystore because I can a) verify the certificate
> chain with openssl and the keystore tells me I have the
> certificates I think I have.

What matters is what the server (Tomcat) is presenting to the client,
not what's actually in the keystore (though usually they are very
closely related).

> I have googled for getting tomcat to give some debug information
> but what I've found so far has no effect.  Can someone point me to
> the official how-to debug ssl issues on tomcat?

There isn't really an official "Tomcat" TLS debugging how-to, because
they are all pretty much the same. Most of the confusion occurs in one
specific place: key/cert management (key, csr, cert, chain, etc.)
because if you don't understand it, it's easy to get lost.

Along with posting your <Connector> configuration, can you post the
output of this command:

$ keytool -list -verbose -keystore [keystorename]

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYWvFWAAoJEBzwKT+lPKRYqdsQAKZxQQz1PF5VH88y1IDRLq2+
qegBtNOF+oTTzueeWveFnUS13stvYBpxNC0jU8GHt1jsbSs13hlxUby7trstAhev
nmQCvd31g+8i7VQOKpUSAyCBHJBrZn9FAhcJDrVdZZP7SInCp4KzmyNnUUEAIgQs
hsqm3LaquabergPUwidXMlBD7P6mZ+74GorGoX06J6/ivaP6RRrxG1OVDeYzH/mZ
ai8x9Q/UOtaFJOrb7tK6JJRNQaiSb7Pryozrdu/81Gi9pDALToden1LWlqa1nvHF
xBpbM1lTEs0W24gACZtaGv2IJsNoFgJ76/S9nLH5NOMDZBNPnpfhoAQrOUH9YHIt
hme4kltU69saE10hkvqrsvVQ5XplXwD4F3q8XnE2JHYv0bTl8cg7fL3yvtPPXUCC
pIe1QioEAu+nKVrpV7KvPfYGhAsxJ2kVcho/bv+sANEWyMEqqfRR/zCnOU5Ge7OE
e7OrQylXVcXQazfV0Hxd62CYCKW0lhx8Vm60q9sr4QcsYr21QRKr6NUWvC8PQTci
XEpyKYEJ4E8CMxpaOqGl9khpQzkCnSxhRPg1nrlsWc/dDML8BnEuwF3xAR4pObP3
BRrMEhldoN/px/TPqTTnNxh9qr2A2Y+K3x/Ptg1VxGXiwFbEcTYVSh5rKaoASsLz
o3RRxtRPiC1NrAlTK2Bc
=AKTz
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org