Pular para o conteúdo principal

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


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

If you need a certificate with a particular information, issue a test 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. The intermediate CA is 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: 

    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 do:

ProductHow to trust the test PKIWhat the samples do
Web PKIInstall 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 PKISecurity context 803517ad-3bbc-4169-b085-60053a8f6dbf.NET: debug builds; other languages: trustLacunaTestRoot
Rest PKI CoreThe same security context, per request or as the subscription's default.NET: debug builds; Java: trustLacunaTestRoot
PKI SDKTrustedRoots with Lacuna Root Test v3 in a LinkedTrustArbitrator.NET: debug builds
PKI ExpresstrustLacunaTestRoot on the operatortrustLacunaTestRoot in the configuration
SignerAdd 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:

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.

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 and 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. 
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:

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:

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

Or in Java:

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

In the 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.

LanguageExample (PAdES with Rest PKI)Switch
PHPphp/plain/public/pades-signature-rest/index.php, through Util::getSecurityContextId()"trustLacunaTestRoot" => true in php/plain/config.php (true by default)
Javajava/springmvc/.../controller/PadesSignatureRestController.java, through Util.getSecurityContext()trustLacunaTestRoot in application.yml (false) and application-dev.yml (true)
.NETdotnet/mvc/PkiSuiteAspNetMvcSample/Controllers/PadesSignatureRestController.cs, through Util.GetSecurityContextId()Debug build: StandardSecurityContexts.LacunaTest under #if DEBUG, PkiBrazil otherwise
Node.jstrustLacunaTestRoot in nodejs/expressmvc/config/*.js
PythonTRUST_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(): 

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 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, Java, PHP, Python and Ruby, and Which certificates are trusted.

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.
  • The Signer samples' 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.

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.

View as Markdown