Check self-signed certificate names and signatures

net/data/ssl/scripts/generate-bad-self-signed.sh

+#!/bin/bash
+
+# Copyright 2016 The Chromium Authors. All rights reserved.
+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+# This script generates self-signed-invalid-name.pem and
+# self-signed-invalid-sig.pem, which are "self-signed" test certificates with
+# invalid names/signatures, respectively.
+
+try() {
+  "$@" || (e=$?; echo "$@" > /dev/stderr; exit $e)
+}

[Ryan Sleevi, 2016/05/26 07:57:08]

The new files have been using "set -e" (yeah, welcome to Google, where things
are inconsistent)

[dadrian, 2016/05/27 01:05:02]

Done.

+
+try rm -rf out
+try mkdir out
+
+openssl genrsa -out out/bad-self-signed.key 2048
+touch out/bad-self-signed-index.txt
+
+# Create two certificate requests with the same key, but different subjects
+SUBJECT_NAME="req_self_signed_a" \
+  try openssl req \
+    -new \
+    -key out/bad-self-signed.key \
+    -out out/ss-a.req \
+    -config ee.cnf
+
+SUBJECT_NAME="req_self_signed_b" \
+  try openssl req \
+    -new \
+    -key out/bad-self-signed.key \
+    -out out/ss-b.req \
+    -config ee.cnf
+
+# Create a normal self-signed certificate from one of these requests
+try openssl x509 \
+  -req \
+  -in out/ss-a.req \
+  -out out/bad-self-signed-root-a.pem \
+  -signkey out/bad-self-signed.key \
+  -days 3650
+
+# Now, for the crazy part. We need to find a section of the signature to modify
+# so that the names match but the signature doesn't. We do this by replacing the
+# first four bytes of the signature with the bytes 0xdead.

[Ryan Sleevi, 2016/05/26 07:57:08]

We try to avoid "we" in comments
(https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/NH-S6KCkr2M
for context)

[dadrian, 2016/05/27 01:05:02]

Done.

+
+# Find the first four hex-encoded bytes of the signature
+bytes=$(
+  openssl x509 -in out/bad-self-signed-root-a.pem -text -noout \
+    | grep -A 1 sha256WithRSA \
+    | tail -n 1 \
+    | tr -d ' ' \
+    | tr -d ':' \
+    | head -c 4)
+
+# Find those bytes in the DER-encoded certificate, and replace them with 'dead'
+openssl x509 -in out/bad-self-signed-root-a.pem -outform DER \
+  | xxd \
+  | sed "s|$bytes|dead|g" \
+  | xxd -r \
+  | openssl x509 -inform DER -outform PEM -out out/self-signed-invalid-sig.pem

[Ryan Sleevi, 2016/05/26 07:57:08]

Why do we need to generate a certificate file with the malformed signature? Why
can't we just munge the signature in the unittest - where we know exactly where
the signature is?

[estark, 2016/05/26 16:26:51]

Ahh, I didn't think of that, that does seem better. So you're suggesting read in
a certificate, mess with the signature, and then use
X509Certificate::CreateFromBytes()? When you say "we know exactly where the
signature is", do you mean hardcode the byte offset? Or is there a nicer way?

[Ryan Sleevi, 2016/05/26 16:34:56]

On 2016/05/26 16:26:51, estark wrote:
 > Ahh, I didn't think of that, that does seem better. So you're suggesting read
in
Could use the ASN.1 parser we have and just skip to the offset. On the con side,
that's more work, and more native, on the plus side, it means less bash
scripting, less coupling to OpenSSL's text form, and less coreutils
dependencies. Mostly I mention it because when I wrote a lot of the original
bash scripts, I was using them in Windows in msys (because I'm weird like that
and because depot-tools includes msys)

I was thinking something like
https://code.google.com/p/chromium/codesearch#chromium/src/net/cert/asn1_util...
in the _unittest.cc file to munge the data, and then CreateFromBytes.

My own gut take is that it'd be more maintainable, but I'm also looking to see
if there's disagreement, or if it's more work than I'm thinking, since it's just
more of a gut take.

[dadrian, 2016/05/26 18:41:36]

I'm less familiar with Chrome development, so take what I say with a grain of
salt. However, in my experience outside of Chrome, having the actual
certificates for various error conditions written to disk, rather than
"ephemeral" certificates generated programmatically during the life of a test,
has always been more useful. For one, certificate files are easier to grok since
you can send them through `openssl x509 -text` or similar. Beyond that, since
it's physically impossible to write certificate-handling code correctly, when
you inevitably find bugs, they're easier to share across various parts of code
that touch certificates, and also easier to verify for (in)correctness.

[estark, 2016/05/27 00:59:13]

Hrm, I am struggling to come up with a strong opinion either way. The openssl
bash stuff is pretty gross -- no offense, David :) -- but I buy the argument
that it's handy to have the actual certificate file around to poke at.

[dadrian, 2016/05/27 01:22:57]

OpenSSL anything is pretty gross. I'd argue that most people interacting with
the test certificates wouldn't have to touch it, though.

+
+# Make a "self-signed" certificate with mismatched names
+try openssl x509 \
+  -req \
+  -in out/ss-b.req \
+  -out out/self-signed-invalid-name.pem \
+  -days 3650 \
+  -CA out/bad-self-signed-root-a.pem \
+  -CAkey out/bad-self-signed.key \
+  -CAserial out/bad-self-signed-serial.txt \
+  -CAcreateserial