---
title: "Test certificates"
description: "Test certificates from the Lacuna Test PKI for development and staging, as ICP-Brasil mock PKCS #12 files, and how to trust them in Web PKI, Rest PKI, Rest PKI Core, PKI SDK, PKI Express and Signer; never trust this PKI in production."
canonical: "https://docs.lacunasoftware.com/en-us/articles/pki-guide/test-certs"
locale: "en"
product: "PKI guide"
last_updated: "2026-10-12"
---

# Test certificates

If you need test certificates to use in a development or staging environment, you can
use one of the certificates in our test PKI.

> **Warning**
>
> The Lacuna Test PKI should never be trusted in a production environment!

**[Download test certificates](https://docs.lacunasoftware.com/en-us/content/test-certs.zip)**

All files are PKCS #12 certificates with password **1234**. The following certificates are included:

* Alan Mathison Turing
    * Email: testturing@lacunasoftware.com
    * ICP-Brasil mock certificate with CPF 56072386105
* Ferdinand Georg Frobenius
    * Email: testfrobenius@lacunasoftware.com
    * ICP-Brasil mock certificate with CPF 87378011126
* Pierre de Fermat
    * Email: test@lacunasoftware.com
    * ICP-Brasil mock certificate with CPF 47363361886
* Wayne Enterprises, Inc
    * Email: test@wayneenterprises.com
    * ICP-Brasil mock certificate with CNPJ 34785515000166
    * Legal representative: Bruce Wayne mock certificate with CPF 47891178631

If you need a certificate with a particular information, [issue a test certificate](https://demos.lacunasoftware.com/en/demos/generate-certificate) yourself.

Always remember to **remove the trust in the Lacuna Test PKI when you're moving to a production environment**. Better yet, use some sort of conditional compilation so that the test PKI is only trusted when running in debug mode.

## What the files contain

* Each file holds only the end-entity certificate and its private key, not the chain. Importing a file does not install the test root or intermediate CA. 
* The certificates are issued by **Lacuna CA Test v7**, which is issued by **Lacuna Root Test v3**. To trust the test PKI, trust that root:
    * Subject: `C=BR, O=ICP-Brasil, OU=Lacuna Software - LS, CN=Lacuna Root Test v3`, valid from 2024-12-16 to 2074-12-16.
    * SHA-256 fingerprint: `BE:1E:84:17:7B:80:F1:88:9A:65:F1:10:10:A8:FB:85:49:5B:E7:0F:FC:3D:83:F5:C6:D6:3A:92:BE:DC:C0:18`.
    * Download: [lacuna-root-test-v3.cer](http://ca.lacunasoftware.com/certs/lacuna-root-test-v3.cer). The intermediate CA is [lacuna-ca-test-v7.cer](http://ca.lacunasoftware.com/certs/lacuna-ca-test-v7.cer).

* The certificates are valid until January 2075, with key usage Digital Signature, Non Repudiation and Key Encipherment, and extended key usage TLS client authentication and e-mail protection. 
* The files use legacy PKCS #12 encryption (3DES for the key, 40-bit RC2 for the certificate, SHA-1 MAC). OpenSSL 3 refuses them with an `unsupported ... RC2-40-CBC` error unless you pass `-legacy`: 

  ```bash
  openssl pkcs12 -legacy -in "Pierre de Fermat.pfx" -passin pass:1234 -nokeys
  ```

## Trusting the test PKI in each product

Each product decides in its own way which roots it trusts, and you have to configure each one to trust the test PKI.
The sections below show how, and what the [sample projects](https://github.com/LacunaSoftware/PkiSuiteSamples) do:

| Product | How to trust the test PKI | What the samples do |
| --- | --- | --- |
| [Web PKI](https://docs.lacunasoftware.com/en-us/articles/pki-guide/test-certs#web-pki) | Install the certificate in the user's store; trust comes from Rest PKI or from the `trustArbitrators` of a local signature | .NET: adds an older test root, which no longer accepts these certificates |
| [Rest PKI](https://docs.lacunasoftware.com/en-us/articles/pki-guide/test-certs#configuring-rest-pki) | Security context `803517ad-3bbc-4169-b085-60053a8f6dbf` | .NET: debug builds; other languages: `trustLacunaTestRoot` |
| [Rest PKI Core](https://docs.lacunasoftware.com/en-us/articles/pki-guide/test-certs#rest-pki-core) | The same security context, per request or as the subscription's default | .NET: debug builds; Java: `trustLacunaTestRoot` |
| [PKI SDK](https://docs.lacunasoftware.com/en-us/articles/pki-guide/test-certs#pki-sdk) | `TrustedRoots` with Lacuna Root Test v3 in a `LinkedTrustArbitrator` | .NET: debug builds |
| [PKI Express](https://docs.lacunasoftware.com/en-us/articles/pki-guide/test-certs#pki-express) | `trustLacunaTestRoot` on the operator | `trustLacunaTestRoot` in the configuration |
| [Signer](https://docs.lacunasoftware.com/en-us/articles/pki-guide/test-certs#signer) | Add the root to the instance's TrustArbitrator (on-premises) | Sign on the sandbox with a test certificate |

## Web PKI

Web PKI lists the certificates in the operating system's certificate store and on connected crypto devices, so a test certificate must be installed before Web PKI can list it. 

**Windows.** Import the `.pfx` file into the current user's **Personal** store. Double-click the file and follow the Certificate Import Wizard (store location **Current User**, password `1234`), or run in PowerShell:

```powershell
Import-PfxCertificate -FilePath ".\Pierre de Fermat.pfx" -CertStoreLocation Cert:\CurrentUser\My -Password (ConvertTo-SecureString 1234 -AsPlainText -Force)
```

Then `certmgr.msc` shows the certificate under **Personal**, with "You have a private key that corresponds to this certificate". See [Get started](https://docs.lacunasoftware.com/en-us/articles/web-pki/get-started). 

TODO(docs): how to install the test PKCS #12 files so that Web PKI lists them on Linux and macOS. No source says which store Web PKI reads on those systems.

**Trust.** Installing the certificate does not make a signature trust it:

* With Rest PKI or Rest PKI Core, the security context of the operation decides: see [Configuring Rest PKI](https://docs.lacunasoftware.com/en-us/articles/pki-guide/test-certs#configuring-rest-pki) and [Rest PKI Core](https://docs.lacunasoftware.com/en-us/articles/pki-guide/test-certs#rest-pki-core).
* For a signature made only with Web PKI, such as `signPdf()`, add Lacuna Root Test v3 to the `trustArbitrators` as a `trustedRoot` arbitrator, with the root's Base64 encoding, in development only. The ASP.NET MVC sample does this in `Views/PadesSignatureWeb/Index.cshtml`, but its `_lacunaTestRoot` (in `Views/Shared/_Layout.cshtml`) is an older root, Lacuna Root Test v1, which expired in January 2025 and is not the root of these certificates: use Lacuna Root Test v3 instead. 

```javascript
trustArbitrators: [
    pki.standardTrustArbitrators.pkiBrazil,
    // Lacuna Software Test Root (development only!)
    { type: 'trustedRoot', trustedRoot: lacunaTestRootBase64 }
]
```

## Configuring Rest PKI

The Lacuna Test PKI security context ID is:

```text
Lacuna Test PKI security context ID (for development purposes only!!!):
803517ad-3bbc-4169-b085-60053a8f6dbf
```

Pass it as the security context of the operation. For instance, to start a PAdES (PDF) signature in PHP:

```php
// Trust Lacuna Test PKI (for development purposes only!!!)
$signatureStarter->setSecurityContext("803517ad-3bbc-4169-b085-60053a8f6dbf");
```

Or in Java:

```java
// Trust Lacuna Test PKI (for development purposes only!!!)
signatureStarter.setSecurityContext(new SecurityContext("803517ad-3bbc-4169-b085-60053a8f6dbf"));
```

In the [PkiSuiteSamples](https://github.com/LacunaSoftware/PkiSuiteSamples) projects you don't edit the sample: every page gets the security context from a `Util` helper, which returns the Lacuna Test PKI context when the project's switch is on. 

| Language | Example (PAdES with Rest PKI) | Switch |
| --- | --- | --- |
| PHP | `php/plain/public/pades-signature-rest/index.php`, through `Util::getSecurityContextId()` | `"trustLacunaTestRoot" => true` in `php/plain/config.php` (`true` by default) |
| Java | `java/springmvc/.../controller/PadesSignatureRestController.java`, through `Util.getSecurityContext()` | `trustLacunaTestRoot` in `application.yml` (`false`) and `application-dev.yml` (`true`) |
| .NET | `dotnet/mvc/PkiSuiteAspNetMvcSample/Controllers/PadesSignatureRestController.cs`, through `Util.GetSecurityContextId()` | Debug build: `StandardSecurityContexts.LacunaTest` under `#if DEBUG`, `PkiBrazil` otherwise |
| Node.js | | `trustLacunaTestRoot` in `nodejs/expressmvc/config/*.js` |
| Python | | `TRUST_LACUNA_TEST_ROOT` in `python/flask/sample/config.py` and `python/django/sample/config.py` |

The .NET sample warns that an on-premises installation of Rest PKI might not have this security context; if yours doesn't, contact developer support. 

From then on, the certificates in our test PKI will be trusted.

## Rest PKI Core

Every Rest PKI Core instance has the standard security context **Lacuna Test PKI (for development purposes only!)**, with the same ID, `803517ad-3bbc-4169-b085-60053a8f6dbf` (`StandardSecurityContexts.LacunaTest` in the .NET client). The instance creates it when it starts, so on-premises instances have it too. It trusts ICP-Brasil, the Windows trust store and Lacuna Root Test v3. 

Use it in one of two ways:

* **Per request**: pass the ID as the `SecurityContextId` when you create a signature session (`CreateSignatureSessionRequest.SecurityContextId`) or prepare a signature (`PrepareSignatureOptions.SecurityContextId`, `securityContextId` in `POST api/signature`). 
* **For the whole subscription**: on the dashboard, choose it in **Settings** > **General settings** > **Default security context**, the security context used when a request does not give one. Only users with the **Admin** or **Manager** role on the subscription see **Settings**. 

When a request gives no security context, Rest PKI Core uses the subscription's default, or else the instance's `General:DefaultSecurityContext` setting, which defaults to PKI Brazil. So, by default, the test certificates are not trusted. 

In the samples, the ASP.NET MVC project passes `StandardSecurityContexts.LacunaTest` in debug builds and `PkiBrazil` otherwise; the Java project passes `SecurityContext.lacunaTest` only when `trustLacunaTestRoot` is `true` in `application.yml`, which ships with `false`. 

TODO(docs): whether core.pki.rest offers test API keys or a trial subscription. The samples ship a trial key for core.pki.rest that expires on 2026-10-31.

## PKI SDK

PKI SDK has no security context: the roots it trusts come from an `ITrustArbitrator`. To trust the test PKI, add Lacuna Root Test v3 as `TrustedRoots` to a `LinkedTrustArbitrator`, only in debug builds. The samples do this in `Util.GetTrustArbitrator()`: 

```cs
var trustArbitrator = new LinkedTrustArbitrator(TrustArbitrators.PkiBrazil, TrustArbitrators.Windows);
#if DEBUG
// For development purposes, we also trust in Lacuna Software's test certificates.
// lacunaRootBytes: Lacuna Root Test v3 (the samples embed it in Base64)
var lacunaRoot = PKCertificate.Decode(lacunaRootBytes);
trustArbitrator.Add(new TrustedRoots(lacunaRoot));
#endif
```

Then use that arbitrator wherever a validation or a signature policy needs one:

* **PAdES**: pass it to the policy, for example `PadesPoliciesForGeneration.GetPadesBasic(trustArbitrator)` and `PadesPoliciesForValidation.GetPadesBasic(trustArbitrator)`. 
* **ICP-Brasil policies** come with their own trust arbitrator, which trusts only the ICP-Brasil roots, so they reject a test certificate even if the rest of your application uses yours. Replace it, in debug builds only:
    * CAdES, such as `CadesPoliciesForGeneration.GetPkiBrazilAdrBasica()`: `policy.ClearTrustArbitrator()`, then `policy.AddTrustArbitrator(trustArbitrator)`.
    * XML, such as `BrazilXmlPolicySpec.GetNFePadraoNacional()`: `policy.ClearTrustArbitrators()`, then `policy.AddTrustArbitrator(trustArbitrator)`.

See [Certificate validation](https://docs.lacunasoftware.com/en-us/articles/pki-sdk/certificates/validation) for `TrustedRoots` and `LinkedTrustArbitrator`.

## PKI Express

Set `trustLacunaTestRoot` on the operator (`trust_lacuna_test_root` in Python and Ruby). See "Trusting in custom certificates" for [Node.js](https://docs.lacunasoftware.com/en-us/articles/pki-express/nodejs/trusting-in-custom-certificates), [Java](https://docs.lacunasoftware.com/en-us/articles/pki-express/java/trusting-in-custom-certificates), [PHP](https://docs.lacunasoftware.com/en-us/articles/pki-express/php/trusting-in-custom-certificates), [Python](https://docs.lacunasoftware.com/en-us/articles/pki-express/python/trusting-in-custom-certificates) and [Ruby](https://docs.lacunasoftware.com/en-us/articles/pki-express/ruby/trusting-in-custom-certificates), and [Which certificates are trusted](https://docs.lacunasoftware.com/en-us/articles/pki-express/validate-signatures#trust). 

## Signer

* By default, a Signer instance accepts only ICP-Brasil certificates. An on-premises instance accepts the Lacuna Test PKI only after you add Lacuna Root Test v3 to its `TrustArbitrator` section and, when signature types are enabled, to `SignatureTypes:Simple:TrustArbitrator` and `SignatureTypes:Qualified:TrustArbitrator`. Advanced signatures use the TrustArbitrator of their security context, which the instance administrator sets in the administration area. See [TrustArbitrator](https://docs.lacunasoftware.com/en-us/articles/signer/on-premises/trust-arbitrator). 
* The [Signer samples](https://github.com/LacunaSoftware/SignerSamples)' public signature scenario (.NET and Node.js) signs on the sandbox, `https://signer-lac.azurewebsites.net`, with a Lacuna test certificate issued by Lacuna CA Test v7 for CPF 56072386105: the file `nodejs/samples/56072386105.pfx`, password `1234`. The participant's `identifier` must equal the certificate's CPF. 
* To sign in the cloud from the embedded signature widget, the online example uses a BirdID test certificate (CPF 026.102.470-10) in the BirdID test environment, paired by scanning a QR code in the BirdID app. See [Embedded signature](https://docs.lacunasoftware.com/en-us/articles/signer/embedded-signature). 

TODO(docs): whether the sandbox trusts the Lacuna Test PKI (the samples imply it does, but no page records a successful run), and which test certificates Dropsigner (`www.dropsigner.com`) accepts.