To improve performance of the vault, we should consider to cache the transport cert. The transport cert is used to wrap the session key for vault payload with the public RSA key of the KRA's transport cert.
ipaclient.plugin.vault
# retrieve transport certificate config = self.api.Command.vaultconfig_show()['result'] transport_cert_der = config['transport_cert'] nss_transport_cert = nss.Certificate(transport_cert_der)
ipaserver.plugins.vault
kra_client = self.api.Backend.kra.get_client() transport_cert = kra_client.system_certs.get_transport_cert() config = {'transport_cert': transport_cert.binary}
The method get_transport_cert performs another HTTPS connection to retrieve the KRA transport cert from Dogtag.
get_transport_cert
The KRA transport cert should be cached on both server side and client side, but at least on the client side. Perhaps it is possible to use certmonger to track the cert and have it automatically reloaded when it is renewed?
== TODOs
Replace tempfile.NamedTemporaryFile with concurrent_open once https://github.com/freeipa/freeipa/pull/467 has landed.
tempfile.NamedTemporaryFile
concurrent_open
Only delete the cached KRA transport cert when Dogtag KRA cannot handle the certificate (e.g. after renewal). Figure out the actual error code / message and propagate a proper exception to the client.
Dogtag's KRA subsystem doesn't report invalid KRA transport cert correctly: https://fedorahosted.org/pki/ticket/2597
I don't know why I put it into 4.5 backlog instead of 4.5, correcting.
Metadata Update from @cheimes: - Issue assigned to someone - Issue set to the milestone: FreeIPA 4.5
Metadata Update from @cheimes: - Custom field affects_doc reset - Custom field blocking reset - Custom field component reset - Custom field on_review reset - Custom field rhbz reset - Custom field type reset - Issue close_status updated to: None - Issue set to the milestone: None (was: FreeIPA 4.5)
Metadata Update from @cheimes: - Custom field affects_doc reset - Issue close_status updated to: None - Issue tagged with: integration
Metadata Update from @pvoborni: - Custom field affects_doc reset - Custom field tester adjusted to wanted - Issue set to the milestone: FreeIPA 4.5
Metadata Update from @jcholast: - Issue assigned to jcholast (was: someone)
master:
Metadata Update from @mbasti: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @cheimes: - Custom field tester reset - Issue set to the milestone: None (was: FreeIPA 4.5) - Issue status updated to: Open (was: Closed)
Metadata Update from @cheimes: - Assignee reset
Changing the change by @cheimes back. It is not clear whether it was changed by accident or on purpose.
Metadata Update from @pvoborni: - Issue assigned to jcholast - Issue set to the milestone: FreeIPA 4.5
Metadata Update from @cheimes: - Issue priority set to: 1 (was: 2) - Issue set to the milestone: None (was: FreeIPA 4.5)
I changed the settings deliberately. Commit 98bb539 has two flaws that must be fixed for 4.5:
I'm not convinced that the in-memory cache of cert instances work under all circumstances. I see some potential combination that may lead to problems, e.g. broken cert file. I rather have a much simpler API that uses just file system and is not build on top of a mutable mapping. Loading of certificates is not performance critical.
The combination of in-memory cache and on-filesystem cache is causing trouble for Custodia and any other forking webserver, too. Since in-memory and on-disk cache are not synced from FS to memory, a new certificate will cause a download on every request again.
There is also no way to enforce a cache refresh without performing a vault read/write operation. I require an API call that forcefully requests and writes the KRA cert on disk.
Metadata Update from @cheimes: - Issue priority set to: None (was: 1)
vaultconfig_show
Metadata Update from @cheimes: - Issue priority set to: 1
Remaining problems are tracked in issue #6787.
Metadata Update from @cheimes: - Issue close_status updated to: duplicate - Issue status updated to: Closed (was: Open)
Metadata Update from @pvoborni: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1436714
Issue linked to bug 1436714
Login to comment on this ticket.