Ah, right. I see what’s going on here, but only by putting together a few obscure facts about Vault that are not well documented.
The “preflight capability check” basically means making a request to sys/internal/ui/mounts/<path you are about to access> to find out what kind of mount it is. The reason software does this, is to find out if it’s about to access a KV v2 secret engine, in which case, inserting an extra /data/ path segment into the URL is necessary, to map between the “conceptual” path as an UI user thinks of it, and the URL path.
Normally, the sys/internal/ui/mounts/:path endpoint doesn’t require any special permissions, as it has built in special logic that allows it to return data, if the user has any permissions at all within the mount being queried.
But in this case, <pki engine>/cert/crl is an anonymously accessible endpoint, so your identity can read it, without having any permissions at all.
In this case, the workaround is to grant permissions to absolutely any path within the relevant mount. Even this policy would actually work:
Is there a way to get a better handling?
Add an additional option like: {{ with secret "pki-root/cert/crl" kv_version="1" }}{{ .Data.certificate }}{{ end }}