Add scripts for generating certs to be used with the quic_server

Add scripts for generating certs to be used with the quic_server

Committed: https://crrev.com/97ee0cdf101bb6eff77242628adf7c399babf14b
Cr-Commit-Position: refs/heads/master@{#349734}

[Ryan Hamilton, 2015-09-10 18:45:50]

rch@chromium.org changed reviewers:
+ rsleevi@chromium.org

[Ryan Hamilton, 2015-09-10 18:45:50]

Can you take a look at this CL? It's mostly based on the scripts in
net/data/ssl/scripts. I plan to update the instructions at
http://www.chromium.org/quic/playing-with-quic to explain how to generate the
certificates and how to use them with the quic server

[Ryan Sleevi, 2015-09-11 04:49:04]

There's no BUG attached, so it's unclear what your goals are, or how best to
review this CL in that context.

For example, questions from this CL:
- Why do you need a new root? Why not just issue a self-signed cert?
- What significance do the names have for testing? Should you use a different
set of IANA reserved names? Is this something people are expected to customize?
- Why only a year validity? What's the concern there - why not 3 days - or 30
years?
- Why does QuicClient not just use something like a MockCertVerifier that takes
a command-line to auto-accept a cert? What are the design tradeoffs there?

Happy to review, just trying to understand the broader context, goals, and
constraints, so that I can provide better review feedback than just mechanical
correctness :)

https://codereview.chromium.org/1330223003/diff/1/net/tools/quic/certs/genera...
File net/tools/quic/certs/generate-certs.sh (right):

https://codereview.chromium.org/1330223003/diff/1/net/tools/quic/certs/genera...
net/tools/quic/certs/generate-certs.sh:45: # Convert the key to pkcs8.
Why? Is this just for the RSAPrivateKeyInfo?

https://codereview.chromium.org/1330223003/diff/1/net/tools/quic/certs/genera...
net/tools/quic/certs/generate-certs.sh:54: # Generate the leaf certificate to be
valid from now to one year in the future.
Why?

https://codereview.chromium.org/1330223003/diff/1/net/tools/quic/certs/leaf.cnf
File net/tools/quic/certs/leaf.cnf (right):

https://codereview.chromium.org/1330223003/diff/1/net/tools/quic/certs/leaf.c...
net/tools/quic/certs/leaf.cnf:21: subjectAltName = @spdy_pooling
*cough* :P

[Ryan Hamilton, 2015-09-11 17:14:03]

On 2015/09/11 04:49:04, Ryan Sleevi wrote:
> There's no BUG attached, so it's unclear what your goals are, or how best to
> review this CL in that context.

Sorry, we spoke about this issue in person a while back and you recommended this
approach, iirc.  In any case, the new quic_server requires a cert and key. If
folks have a legit cert then they can of course use that. But some folks won't,
so we want to provide super simple instructions for using the quic_server.
Hence, either checking a cert/key into the repository (which you thought was a
bad idea because then "Everyone" would have that cert and might be able it do
bad things to quic developers) or a script to generate a cert.

> For example, questions from this CL:
> - Why do you need a new root? Why not just issue a self-signed cert?

Hm. I tried that, but was unable to make it work. Perhaps you can help me figure
out how to do it. When I point Chrome at quic_server using a self-signed cert
(which I've told OS X to trust) I get ERR_CERT_AUTHORITY_INVALID. I'm happy to
go the self-signed route though if there's a way to make it work. That'd be much
simpler.

> - What significance do the names have for testing? Should you use a different
> set of IANA reserved names? Is this something people are expected to
customize?

These were basically arbitrary. I didn't want to use an "important" site which
would potentially be dangerous to MitM. But I'm not married to these. I suspect
some folks might customize the list.

> - Why only a year validity? What's the concern there - why not 3 days - or 30
> years?

Totally arbitrary. 1 year seemed convenient. Do you prefer either of those?

> - Why does QuicClient not just use something like a MockCertVerifier that
takes
> a command-line to auto-accept a cert? What are the design tradeoffs there?

QuicClient is not involved here. This is for making Chrome talk to the quic
server. And Chrome, of course, uses a real CertVerifier.
 
> Happy to review, just trying to understand the broader context, goals, and
> constraints, so that I can provide better review feedback than just mechanical
> correctness :)

Thanks

[Ryan Hamilton, 2015-09-11 17:14:11]

https://codereview.chromium.org/1330223003/diff/1/net/tools/quic/certs/genera...
File net/tools/quic/certs/generate-certs.sh (right):

https://codereview.chromium.org/1330223003/diff/1/net/tools/quic/certs/genera...
net/tools/quic/certs/generate-certs.sh:45: # Convert the key to pkcs8.
On 2015/09/11 04:49:04, Ryan Sleevi wrote:
> Why? Is this just for the RSAPrivateKeyInfo?

The ProofSource that we implemented requires the key to be in pkcs8 format.

https://codereview.chromium.org/1330223003/diff/1/net/tools/quic/certs/genera...
net/tools/quic/certs/generate-certs.sh:54: # Generate the leaf certificate to be
valid from now to one year in the future.
On 2015/09/11 04:49:04, Ryan Sleevi wrote:
> Why?

Why not? :> Seemed like a convenient period. But if you have period you'd
prefer, I'm happy to do that.

https://codereview.chromium.org/1330223003/diff/1/net/tools/quic/certs/leaf.cnf
File net/tools/quic/certs/leaf.cnf (right):

https://codereview.chromium.org/1330223003/diff/1/net/tools/quic/certs/leaf.c...
net/tools/quic/certs/leaf.cnf:21: subjectAltName = @spdy_pooling
On 2015/09/11 04:49:04, Ryan Sleevi wrote:
> *cough* :P

Done.

[wjywbs, 2015-09-11 21:24:26]

On 2015/09/11 17:14:03, Ryan Hamilton wrote:
> On 2015/09/11 04:49:04, Ryan Sleevi wrote:
> > - Why do you need a new root? Why not just issue a self-signed cert?
> 
> Hm. I tried that, but was unable to make it work. Perhaps you can help me
figure
> out how to do it. When I point Chrome at quic_server using a self-signed cert
> (which I've told OS X to trust) I get ERR_CERT_AUTHORITY_INVALID. I'm happy to
> go the self-signed route though if there's a way to make it work. That'd be
much
> simpler.
> 

I did some testing with Chrome and quic_server. I had to import the self signed
cert in the system and set SAN in the cert to have IP 127.0.0.1 and DNS
localhost. Otherwise Chrome and quic_client will fail with
ERR_CERT_COMMON_NAME_INVALID. There is no interstitial shown if the cert is
invalid.

https://code.google.com/p/chromium/codesearch#chromium/src/net/quic/crypto/pr...

[Ryan Hamilton, 2015-09-18 14:20:40]

On 2015/09/11 17:14:11, Ryan Hamilton wrote:
>
https://codereview.chromium.org/1330223003/diff/1/net/tools/quic/certs/genera...
> File net/tools/quic/certs/generate-certs.sh (right):
> 
>
https://codereview.chromium.org/1330223003/diff/1/net/tools/quic/certs/genera...
> net/tools/quic/certs/generate-certs.sh:45: # Convert the key to pkcs8.
> On 2015/09/11 04:49:04, Ryan Sleevi wrote:
> > Why? Is this just for the RSAPrivateKeyInfo?
> 
> The ProofSource that we implemented requires the key to be in pkcs8 format.
> 
>
https://codereview.chromium.org/1330223003/diff/1/net/tools/quic/certs/genera...
> net/tools/quic/certs/generate-certs.sh:54: # Generate the leaf certificate to
be
> valid from now to one year in the future.
> On 2015/09/11 04:49:04, Ryan Sleevi wrote:
> > Why?
> 
> Why not? :> Seemed like a convenient period. But if you have period you'd
> prefer, I'm happy to do that.
> 
>
https://codereview.chromium.org/1330223003/diff/1/net/tools/quic/certs/leaf.cnf
> File net/tools/quic/certs/leaf.cnf (right):
> 
>
https://codereview.chromium.org/1330223003/diff/1/net/tools/quic/certs/leaf.c...
> net/tools/quic/certs/leaf.cnf:21: subjectAltName = @spdy_pooling
> On 2015/09/11 04:49:04, Ryan Sleevi wrote:
> > *cough* :P
> 
> Done.

Sleevi, have you had a chance to look into mechanisms to trust self-signed
certs?

[Ryan Hamilton, 2015-09-18 16:40:12]

As per our chat, I've added 3-day expiration to both certs and added
nameConstraints as well.. PTAL.

Thanks!

[Ryan Sleevi, 2015-09-18 16:47:20]

You don't need some of the ENV bits because you're not intending this to be able
to regenerate a class of certs, but it doesn't do any harm, so LGTM % nit.

https://codereview.chromium.org/1330223003/diff/40001/net/tools/quic/certs/ge...
File net/tools/quic/certs/generate-certs.sh (right):

https://codereview.chromium.org/1330223003/diff/40001/net/tools/quic/certs/ge...
net/tools/quic/certs/generate-certs.sh:3: # Copyright 2013 The Chromium Authors.
All rights reserved.
2015

https://codereview.chromium.org/1330223003/diff/40001/net/tools/quic/certs/ge...
net/tools/quic/certs/generate-certs.sh:57: -days 3\
add a space here

[Ryan Hamilton, 2015-09-18 19:08:42]

Thanks!

https://codereview.chromium.org/1330223003/diff/40001/net/tools/quic/certs/ge...
File net/tools/quic/certs/generate-certs.sh (right):

https://codereview.chromium.org/1330223003/diff/40001/net/tools/quic/certs/ge...
net/tools/quic/certs/generate-certs.sh:3: # Copyright 2013 The Chromium Authors.
All rights reserved.
On 2015/09/18 16:47:20, Ryan Sleevi wrote:
> 2015

Done.

https://codereview.chromium.org/1330223003/diff/40001/net/tools/quic/certs/ge...
net/tools/quic/certs/generate-certs.sh:57: -days 3\
On 2015/09/18 16:47:20, Ryan Sleevi wrote:
> add a space here

Done.

[Ryan Hamilton, 2015-09-18 19:08:46]

The CQ bit was checked by rch@chromium.org

[Ryan Hamilton, 2015-09-18 19:08:47]

The patchset sent to the CQ was uploaded after l-g-t-m from rsleevi@chromium.org
Link to the patchset: https://codereview.chromium.org/1330223003/#ps60001
(title: "fix comments")

[commit-bot: I haz the power, 2015-09-18 19:09:18]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1330223003/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1330223003/60001

[commit-bot: I haz the power, 2015-09-18 19:21:58]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-09-18 19:22:45]

Patchset 4 (id:??) landed as
https://crrev.com/97ee0cdf101bb6eff77242628adf7c399babf14b
Cr-Commit-Position: refs/heads/master@{#349734}