diff options
author | Randy Bush <randy@psg.com> | 2017-04-27 12:28:37 +0900 |
---|---|---|
committer | Randy Bush <randy@psg.com> | 2017-04-27 12:28:37 +0900 |
commit | 6f9e6ae980f50dcc67105eed2b6a8f589cb44de2 (patch) | |
tree | 0b709e01445869305a4d7dd824080b9d4bd7127f /doc/quickstart/xenial-ca.md | |
parent | c6166c992f097799db673ce107ad24740654c54f (diff) |
section on Checking Root Cert from sra
Diffstat (limited to 'doc/quickstart/xenial-ca.md')
-rw-r--r-- | doc/quickstart/xenial-ca.md | 54 |
1 files changed, 54 insertions, 0 deletions
diff --git a/doc/quickstart/xenial-ca.md b/doc/quickstart/xenial-ca.md index ebdfc182..d1975def 100644 --- a/doc/quickstart/xenial-ca.md +++ b/doc/quickstart/xenial-ca.md @@ -420,3 +420,57 @@ root certificate is how the RP finds RRDP, not the other way around), so you'll need to put a copy of the root certificate in the location named by the HTTPS URI in the TAL (/usr/share/rpki/rrdp-publication/ in the default Ubuntu setup). + +## Checking the Root Certificate + +In general there isn't a root.cer file with the new code: the root +RPKI certificate is just another RPKI CA certificate (self-signed, but +otherwise not significantly different), named with a g(SKI) filename +like all the other RPKI objects. + +What matters is: + + * That the URI in the TAL match the filename of the root certificate. + How one does that is somewhat arbitrary, eg, one play games with + Apache aliases given sufficient reason, but the simple approach is + just to drop the root certificate into the same trees already being + served by rsyncd and Apache. The extract_root_tal command makes + certain assumptions about where you're going to do that, feel free + to edit the URI in the TAL if necessary to make this work. + + * That the public key in the TAL match the public key in the + self-signed RPKI root certificate. This is the test that appears to + be failing according to the report above. This usually means that + one is not using the TAL one thought one was, or that the URI in + that TAL is pointing to the wrong root certificate, or something on + that order. + +If you have the self-signed certificate in hand, it's not hard to +extract the public key from it using the OpenSSL command line tool, +eg: + +``` +$ openssl x509 -inform DER -in foo.cer -noout -pubkey +``` + +will send the public key to stdout in PEM format, which is enough for +a quick visual check on whether the public key matches the one in the +TAL. If you want to do a full binary comparison of the public key in +a certificate with one in a TAL, you'll need a few more commands to +whack everything into the right format, something like: + +``` +$ openssl x509 -inform DER -in foo.cer -noout -pubkey | openssl pkey -pubin -outform DER -out foo.cer.key + +$ sed -n '/^$/,$p' foo.tal | openssl enc -d -a -out foo.tal.key + +$ diff -qs foo.cer.key foo.tal.key +``` + +That's essentially what the relying party code does when checking the +key in a TAL, although of course it implements the checks directly. + +There are other tools which will let you examine the ASN.1 if you have +some reason to do so, but in this case it's not all that interesting, +any valid RPKI root key will have identical values for all but one +field of the ASN.1, and that field is a 2048-bit hexadecimal integer. |