Skip to main content
Version: 4.42

How Redtrust controls certificate use

Overview​

Redtrust secures and governs the use of every digital certificate placed under its custody. Protecting digital identity involves more than one layer, and Redtrust owns a specific, well-defined one. This page explains the layer Redtrust controls, how it works, and how it fits alongside the other layers of your security.

The certificate layer​

When you upload a certificate to Redtrust, the platform takes custody of its private key. The key can never be extracted, and the certificate is never exposed directly to users or applications (see Certificates). From that point on, every use of the certificate passes through the agent — and that is what gives you control over it:

  • Every use is traced: Each operation is recorded as an event, giving you a complete history of when and how each certificate was used (see Events).
  • Use is governed by policy: Policies decide which users can use each certificate, on which sites and applications, and at what times (see Policies).
  • Access is filtered by destination: When the destination service exposes identifiable URLs, policies allow or block access per site or per path. For gateways or applications that present a single login for several services, see Mapped sites.

This is the layer Redtrust makes airtight: a custodied certificate cannot be used without going through these controls.

Control follows custody​

A certificate's control begins the moment it comes under Redtrust's custody. A certificate that lives only on a user's machine is, by nature, uncontrolled — it can be copied, used without a trace, and is easy to leak. Bringing that certificate into Redtrust is exactly what replaces that uncontrolled state with centralized, policy-based oversight.

So the path to controlling a certificate is simple: upload it to the platform. Everything from that point on is secured, traced, and governed.

Where Redtrust fits in your security​

Securing digital identity works as a set of layers, each handled by the system best suited to it. The layers you operate are:

  • Redtrust: Secures the private key and governs how each custodied certificate is used — who can use it, where, and when.
  • Your network controls: Firewalls and proxies handle traffic to and from sites.

Beyond the layers you operate, the destination service — the website or online service you sign in to with a certificate, such as the AEAT or another public-administration portal — sets its own rules for what you can do once you're inside.

Together, these layers form defense in depth, and Redtrust makes the certificate layer one you can fully rely on.

What this means in practice​

Because every custodied certificate is secured, traced, and policy-controlled, you can grant precise, per-user access. One user might be allowed to use a certificate across an entire public-administration site, while colleagues are restricted to only the procedures they need, with everything else denied by default — a level of control that doesn't exist when certificates live on local machines.

Scoping access to a single procedure comes down to policy and site design — see Scoping access to a specific procedure.

Scoping access to a specific procedure​

Allowing or blocking an individual procedure is a matter of policy and site design within the certificate layer. Two characteristics of public-administration sites shape how you do it.

A procedure can be reached through more than one URL. A user might open it directly or arrive through a related procedure. Policy filtering acts on the URL, so to scope a procedure you account for every path that leads to it — blocking a single URL leaves the others open.

Those URLs come in two shapes:

  • A dedicated application URL, where the procedure has its own path and the year or variant is only a segment within it. A single wildcard rule covers every variant.
  • A shared endpoint, where many procedures — or every document — pass through the same path, distinguished only by a per-item token such as a verification code. The path alone identifies nothing specific, so you enumerate each token (for example, one entry per fiscal year). A rule on the shared path without the token would block unrelated items too.

You can scope from either direction:

Was this page helpful?