Re: Test keys and certs

2017-08-15 Thread Mark Thomas
On 14 August 2017 21:03:34 BST, Christopher Schultz 
 wrote:
>Mark,
>
>On 8/8/17 9:03 AM, Mark Thomas wrote:
>> On 08/08/17 13:59, George Stanchev wrote:
>> 
>> 
>> 
>>> Is it possible the recent changes [1] has affected it? Chrome no
>longer looks in CN, which is ignored but rather expects SAN to be
>filled up. Perhaps Tomcat's test certs lack SAN?
>>>
>>> [1] https://www.thesslstore.com/blog/security-changes-in-chrome-58/
>> 
>> That did affect the server cert and we fixed that a little while ago.
>I
>> don't believe it applies to user certs. The new user cert doesn't
>have a
>> SAN and it is now working correctly in Chrome.
>
>Is "now" working, or is "not" working in Chrome?

Now working. I.e. the user certificate does not need a SAN to work correctly.

Mark


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Test keys and certs

2017-08-14 Thread Christopher Schultz
Mark,

On 8/8/17 9:03 AM, Mark Thomas wrote:
> On 08/08/17 13:59, George Stanchev wrote:
> 
> 
> 
>> Is it possible the recent changes [1] has affected it? Chrome no longer 
>> looks in CN, which is ignored but rather expects SAN to be filled up. 
>> Perhaps Tomcat's test certs lack SAN?
>>
>> [1] https://www.thesslstore.com/blog/security-changes-in-chrome-58/
> 
> That did affect the server cert and we fixed that a little while ago. I
> don't believe it applies to user certs. The new user cert doesn't have a
> SAN and it is now working correctly in Chrome.

Is "now" working, or is "not" working in Chrome?

-chris



signature.asc
Description: OpenPGP digital signature


Re: Test keys and certs

2017-08-08 Thread Konstantin Kolinko
2017-08-08 16:03 GMT+03:00 Mark Thomas :
> On 08/08/17 13:59, George Stanchev wrote:
>
> 
>
>> Is it possible the recent changes [1] has affected it? Chrome no longer 
>> looks in CN, which is ignored but rather expects SAN to be filled up. 
>> Perhaps Tomcat's test certs lack SAN?
>>
>> [1] https://www.thesslstore.com/blog/security-changes-in-chrome-58/
>
> That did affect the server cert and we fixed that a little while ago. I
> don't believe it applies to user certs. The new user cert doesn't have a
> SAN and it is now working correctly in Chrome.

Interesting.

It means that for a simple self-signed cert the instructions [1] have
to be updated.

Looking at docs [2], there are examples of using '-ext' switch to set a SAN

keytool -alias ca -gencert -ext san=dns:ca1

Also -genkey switch was renamed to -genkeypair.


[1] tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html
[2] https://docs.oracle.com/javase/8/docs/technotes/tools/windows/keytool.html

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Test keys and certs

2017-08-08 Thread Mark Thomas
On 08/08/17 13:59, George Stanchev wrote:



> Is it possible the recent changes [1] has affected it? Chrome no longer looks 
> in CN, which is ignored but rather expects SAN to be filled up. Perhaps 
> Tomcat's test certs lack SAN?
> 
> [1] https://www.thesslstore.com/blog/security-changes-in-chrome-58/

That did affect the server cert and we fixed that a little while ago. I
don't believe it applies to user certs. The new user cert doesn't have a
SAN and it is now working correctly in Chrome.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



RE: Test keys and certs

2017-08-08 Thread George Stanchev


-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Tuesday, August 08, 2017 5:23 AM
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Test keys and certs

All,

Just a heads up.

A few days ago I started to look at bug 59423. I saw all sorts of errors when I 
tried to configure a clean Tomcat build for CLIENT-CERT.

As I dug into the errors it appeared that Tomcat wasn't handling an unexpected 
connection close during the renegotiation. I have a patch for this that I'll 
commit once I have completed some more testing.

I also spent a long time trying to figure out why CLIENT-CERT was failing 
unexpectedly in some cases. The short answer is that it fails in Chrome but not 
with FireFox nor with openssl s_client.

The failure in Chrome occurs when it tries to find a matching user cert for the 
provided trusted certs. For some reason Chrome can't match our current user 
test cert with the CA. My guess is that expects/requires more fields to be 
populated than just C and CN.

I've been experimenting with a new CA created from scratch that populates more 
of the fields and this does work with Chrome.

Therefore, I plan to replace our current test CA with the new one I have 
created and, therefore, also replace all the test keys and certs used in the 
unit tests. I'll also update the notes for creating these files and the 
openssl.cnf with a few more defaults.

I might even get around to looking at 59423 ;)

Mark

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=59423

-



Is it possible the recent changes [1] has affected it? Chrome no longer looks 
in CN, which is ignored but rather expects SAN to be filled up. Perhaps 
Tomcat's test certs lack SAN?

[1] https://www.thesslstore.com/blog/security-changes-in-chrome-58/


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Test keys and certs

2017-08-08 Thread Mark Thomas
All,

Just a heads up.

A few days ago I started to look at bug 59423. I saw all sorts of errors
when I tried to configure a clean Tomcat build for CLIENT-CERT.

As I dug into the errors it appeared that Tomcat wasn't handling an
unexpected connection close during the renegotiation. I have a patch for
this that I'll commit once I have completed some more testing.

I also spent a long time trying to figure out why CLIENT-CERT was
failing unexpectedly in some cases. The short answer is that it fails in
Chrome but not with FireFox nor with openssl s_client.

The failure in Chrome occurs when it tries to find a matching user cert
for the provided trusted certs. For some reason Chrome can't match our
current user test cert with the CA. My guess is that expects/requires
more fields to be populated than just C and CN.

I've been experimenting with a new CA created from scratch that
populates more of the fields and this does work with Chrome.

Therefore, I plan to replace our current test CA with the new one I have
created and, therefore, also replace all the test keys and certs used in
the unit tests. I'll also update the notes for creating these files and
the openssl.cnf with a few more defaults.

I might even get around to looking at 59423 ;)

Mark


[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=59423

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org