summaryrefslogtreecommitdiffstats
path: root/base/server/python
diff options
context:
space:
mode:
authorChristina Fu <cfu@dhcp-16-189.sjc.redhat.com>2016-10-05 16:09:24 -0700
committerMatthew Harmsen <mharmsen@redhat.com>2016-10-10 16:38:07 -0600
commit35aff85b5b0c00d301a0122429b54a7ca9a90c7d (patch)
treee187564b2bd3f74869f0182bff8e6ec0cc64b1ec /base/server/python
parent30e67f3306c8feea5adfa7b1c677c02298c89bcb (diff)
downloadpki-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