Summary

Root Cause

if plugin.requires key:
  if not cert.private key:
    return (..., 400)
  else:
    if g.current user != cert.user:
      owner role = role service.get by name(cert.owner)
      permission = CertificatePermission(owner role, [x.name for x in cert.roles])
      if not permission.can():
        return (..., 403)
 
log service.create(g.current user, "key view", certificate=cert)  # always logged
extension, passphrase, data = plugin.export(
  cert.body, cert.chain, cert.private key, options
)

1. The structural defect is latent and silent - any future requires key = False ExportPlugin that does read cert.private key will inherit the bypass with no test or code-review signal.
2. The unconditional log service.create(..., "key view", ...) call falsely records key-view events for callers who never viewed a key, weakening incident-response signal.

Affected Endpoints

Impact

• Any authenticated user can mint a Java truststore (java-truststore-jks plugin) containing any certificate's public body and chain, without owning the certificate or holding a role with permission over it.
• The audit log records a key view event for the calling user against that certificate, despite no private key having been accessed. Defenders investigating apparent key-view events will encounter false positives that they cannot distinguish from genuine accesses.

• A future ExportPlugin author who sets requires key = False because their plugin can operate without a key (e.g., for a fall-back code path) but still uses the key when one is provided will silently leak private keys to any authenticated user. The same code review that approves the plugin will not flag this — the authorization invariant is held by a structurally distant if-branch in the view, not by the plugin itself.

Remediation

# Authorization first, unconditionally.
if g.current user != cert.user:
  owner role = role service.get by name(cert.owner)
  permission = CertificatePermission(owner role, [x.name for x in cert.roles])
  if not permission.can():
    return (dict(message="You are not authorized to export this certificate."), 403)
 
if plugin.requires key:
  if not cert.private key:
    return (dict(message="Plugin requires a key but none is present."), 400)
  log service.create(g.current user, "key view", certificate=cert)  # only when key actually accessed
 
extension, passphrase, data = plugin.export(
  cert.body, cert.chain, cert.private key, options
)

Steps to Reproduce

1. Set up Lemur with default configuration. Create an admin user admin and a non-admin user eve with the read-only role (or any role without certificate permissions).
2. As admin, issue a certificate. Note its id.
3. As eve, invoke export with the java-truststore-jks plugin:

  curl -X POST https://lemur.local/api/1/certificates/<cert id>/export 
    -H "Authorization: Bearer <eve jwt>" 
    -H "Content-Type: application/json" 
    -d '{
       "plugin": {
        "slug": "java-truststore-jks",
        "plugin options": [
         {"name": "passphrase", "value": "test"}
        ]
       }
      }'

4. Observe HTTP 200 with a base64-encoded JKS truststore in the response. eve had no permission over admin's certificate, yet successfully exported its public material.
5. Inspect the audit log table or lemur logs list:

  psql lemur -c "SELECT user id, log type, certificate id, logged at FROM logs
         WHERE certificate id = <cert id> ORDER BY logged at DESC LIMIT 1;"