diff options
| author | Christina Fu <cfu@dhcp-16-189.sjc.redhat.com> | 2016-10-05 16:09:24 -0700 |
|---|---|---|
| committer | Matthew Harmsen <mharmsen@redhat.com> | 2016-10-10 16:38:07 -0600 |
| commit | 35aff85b5b0c00d301a0122429b54a7ca9a90c7d (patch) | |
| tree | e187564b2bd3f74869f0182bff8e6ec0cc64b1ec /base/server/python | |
| parent | 30e67f3306c8feea5adfa7b1c677c02298c89bcb (diff) | |
| download | pki-35aff85b5b0c00d301a0122429b54a7ca9a90c7d.tar.gz pki-35aff85b5b0c00d301a0122429b54a7ca9a90c7d.tar.xz pki-35aff85b5b0c00d301a0122429b54a7ca9a90c7d.zip | |
Ticket #2496 Cert/Key recovery is successful when the cert serial number and key id on the ldap user mismatches
Problem: There are two ways to recover the keys with
a. by cert
b. by keyId
When recovering by cert, KRA checks if cert and key matches before returning; However, in case of recovering by keyId, KRA has no way of checking. TPS also has no way of checking because the recovered private keys are warpped.
This patch adds a control parameter externalReg.recovery.byKeyID to determine if TPS should recover keys by keyIDs. By default, it is false, so certs are used to search for key record and recover.
Code summary for externalReg key recovery:
config default: externalReg.recover.byKeyID=false
Recover either by keyID or by cert
When recovering by keyid: externalReg.recover.byKeyID=true
- keyid in record indicates actual recovery;
- missing of which means retention;
When recovering by cert: externalReg.recover.byKeyID=false
- keyid field needs to be present
but the value is not relevant and will be ignored (a "0" would be fine)
- missing of keyid still means retention;
(In hindsight, recovery by keyid is probably more accident-prone and should be discouraged)
Diffstat (limited to 'base/server/python')
0 files changed, 0 insertions, 0 deletions
