#6652 [vault] cache KRA transport cert
Closed: duplicate 7 years ago Opened 7 years ago by cheimes.

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.

client

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)

server

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.

Caching

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.

  • 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

7 years ago

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)

7 years ago

Metadata Update from @cheimes:
- Custom field affects_doc reset
- Issue close_status updated to: None
- Issue tagged with: integration

7 years ago

Metadata Update from @pvoborni:
- Custom field affects_doc reset
- Custom field tester adjusted to wanted
- Issue set to the milestone: FreeIPA 4.5

7 years ago

Metadata Update from @jcholast:
- Issue assigned to jcholast (was: someone)

7 years ago

master:

  • 98bb539 vault: cache the transport certificate on client

Metadata Update from @mbasti:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

7 years ago

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)

7 years ago

Metadata Update from @cheimes:
- Assignee reset

7 years ago

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

7 years ago

Metadata Update from @cheimes:
- Issue priority set to: 1 (was: 2)
- Issue set to the milestone: None (was: FreeIPA 4.5)

7 years ago

I changed the settings deliberately. Commit 98bb539 has two flaws that must be fixed for 4.5:

  1. Don't cache certificates in memory
  2. Missing API to enforce a cache refresh

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)

7 years ago
  1. Unless you provide actual steps that lead to problematic behavior I don't consider this an issue.
  2. Call vaultconfig_show to refresh the cache.
  1. Unless the transport cache feature is fully covered with automatic unit tests, I consider it a blocker. I'm 99% sure the in-memory cache leads to bad behavior for a forking service, because the in-memory cache takes precedence over on-fs cache. My instincts tell me that three potential scenarios could lead to bad behavior:
  • Forking service, cert cached in main process, cache invalidated in request handler process
  • cert cached in-memory, missing on fs, cert is invalidated
  • cert cached in-memory, file broken on fs, certs is invalidated
  1. vaultconfig_show has no documentation or comment that explains it forcefully refreshes the transport cert.

Metadata Update from @cheimes:
- Issue priority set to: 1

7 years ago

Remaining problems are tracked in issue #6787.

Metadata Update from @cheimes:
- Issue close_status updated to: duplicate
- Issue status updated to: Closed (was: Open)

7 years ago

Metadata Update from @pvoborni:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1436714

7 years ago

Metadata Update from @pvoborni:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1436714

7 years ago

Login to comment on this ticket.

Metadata