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 <
ch...@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 <
> > ch...@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 <
> >>>> ch...@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-unsubscr...@tomcat.apache.org
> >>>>> For additional commands, e-mail:
> >>>>> users-h...@tomcat.apache.org
> >>>>>
> >>>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
