--- title: "Lacuna TSA" description: "Lacuna TSA, servidor de carimbo de tempo (RFC 3161): os padrões internacionais e da ICP-Brasil que segue, como um carimbo do tempo ICP-Brasil é emitido, o conteúdo do carimbo e como solicitá-lo." canonical: "https://docs.lacunasoftware.com/articles/tsa" locale: "pt-BR" product: "TSA" last_updated: "2026-10-12" --- # Lacuna TSA O Lacuna TSA é um servidor de carimbo de tempo (*Time Stamping Authority*, TSA). Você envia o hash de um dado e recebe um **carimbo de tempo** (*time-stamp token*): uma estrutura assinada pela TSA que prova que o dado existia em uma data e hora. É o carimbo de tempo que permite validar uma assinatura digital depois que o certificado do signatário expira. A Lacuna Software oferece o Lacuna TSA como serviço em nuvem (SaaS), e você também pode ter uma instância na sua própria infraestrutura ([on-premises](https://docs.lacunasoftware.com/articles/tsa/on-premises)). ## Padrões suportados ### Padrões internacionais | Padrão | Como o Lacuna TSA o utiliza | |---|---| | RFC 3161, *Time-Stamp Protocol* (TSP) | Formatos da requisição (`TimeStampReq`) e da resposta (`TimeStampResp`), enviadas por HTTP com os content types `application/timestamp-query` e `application/timestamp-response` | | RFC 5652, *Cryptographic Message Syntax* (CMS) | O carimbo é um `SignedData` CMS cujo conteúdo é a estrutura `TSTInfo` (tipo de conteúdo `id-ct-TSTInfo`) | | RFC 5816, ESSCertIDv2 para a RFC 3161 | O carimbo identifica o certificado da TSA com o atributo `signing-certificate-v2` (RFC 5035), com hash SHA-256 | | RFC 5755, certificados de atributo | Formato do certificado de atributo opcional incluído em todo carimbo, como o alvará da ICP-Brasil ([veja abaixo](https://docs.lacunasoftware.com/articles/tsa#icp-brasil)) | Os carimbos são emitidos sob a política de TSA da Lacuna Software, OID `1.3.6.1.4.1.46332.4.1` ([OIDs da Lacuna Software](https://docs.lacunasoftware.com/articles/asn1#tsa-policies)), a menos que você configure outra política na sua instância, como a atribuída à sua autoridade de carimbo de tempo. ### ICP-Brasil Na ICP-Brasil, os carimbos de tempo — "carimbos do tempo", no vocabulário da ICP-Brasil — são emitidos por Autoridades de Carimbo do Tempo (ACTs) credenciadas, em Servidores de Carimbo do Tempo (SCTs) conectados à Rede de Carimbo do Tempo da ICP-Brasil. Só são aceitos na ICP-Brasil carimbos emitidos por SCT com alvará fornecido por um Sistema de Auditoria e Sincronismo (SAS). As regras estão nestes documentos: | Documento | O que define | No Lacuna TSA | |---|---|---| | DOC-ICP-11, visão geral do sistema de carimbo do tempo | Os participantes: ACT, SCT, a Entidade de Auditoria do Tempo (EAT), seus SASs e a Fonte Confiável do Tempo (FCT). Requisições e respostas seguem a RFC 3161 | RFC 3161 via HTTP | | DOC-ICP-12, requisitos mínimos para as declarações de práticas das ACTs | O perfil do carimbo (item 7.2): `ordering` falso ou ausente, uma precisão declarada, tratamento de `nonce` e `reqPolicy` e o alvará vigente. O certificado do SCT tem o uso estendido de chave `id-kp-timeStamping` | `ordering` falso, precisão (`accuracy`) de 1 segundo, `nonce` copiado da requisição, `reqPolicy` comparado com `Tsa:PolicyId`, alvará lido de `Tsa:Tac` | | DOC-ICP-12.01, perfil do alvará do carimbo do tempo | O alvará é um certificado de atributo (RFC 5755) assinado pelo SAS | O alvará configurado em `Tsa:Tac` vai em todo carimbo, no atributo assinado `signer-attributes` | | DOC-ICP-13, requisitos mínimos para as políticas de carimbo do tempo | Cada política de carimbo do tempo (PCT) da ACT recebe um OID `2.16.76.1.6.n` no credenciamento | Configure o OID da PCT em `Tsa:PolicyId` | O formato do carimbo é só uma parte. Para emitir carimbos do tempo ICP-Brasil, a ACT que opera o servidor precisa ser credenciada pela AC Raiz, o certificado do SCT precisa ser um certificado ICP-Brasil, a chave do SCT precisa ser gerada e guardada em um módulo de segurança criptográfico (MSC), e o relógio do SCT precisa ser sincronizado e auditado por um SAS, que só emite o alvará enquanto o relógio estiver dentro da precisão declarada na política. No Lacuna TSA, a chave pode ficar no [Amplia](https://docs.lacunasoftware.com/articles/amplia), que suporta HSMs (configure `KeyStore:Type` como `Amplia`). ## Como um carimbo do tempo ICP-Brasil é emitido O diagrama abaixo mostra o Lacuna TSA operando como SCT de uma ACT credenciada: a sincronização com a Rede de Carimbo do Tempo, que acontece continuamente, e a emissão de um carimbo, do pedido à verificação. ![Como um carimbo do tempo ICP-Brasil é emitido pelo Lacuna TSA, passo a passo](https://docs.lacunasoftware.com/images/tsa/issuance-sequence-icp-brasil-pt.svg) 0. Continuamente, a EAT mantém a escala de tempo da FCT rastreável à UTC e, pelos SASs, sincroniza e audita o relógio do SCT. Enquanto o relógio estiver dentro da precisão, o SAS emite o alvará do SCT, que a ACT informa ao Lacuna TSA na configuração `Tsa:Tac`. 1. Sua aplicação calcula o hash do documento, por exemplo com SHA-256. Só o hash é enviado: a TSA nunca vê o documento. 1. Sua aplicação envia uma requisição de carimbo do tempo (TSQ, um `TimeStampReq`) em um `POST` HTTP para a raiz do servidor (`/`), com o header `Content-Type: application/timestamp-query`. A requisição pode indicar, em `reqPolicy`, o OID da PCT. Se houver [autenticação](https://docs.lacunasoftware.com/articles/tsa/on-premises/configure-auth) configurada, a requisição também leva o header `Authorization` (`Basic` ou `Bearer`). As rotas antigas `/timestamp` e `/timestamper` aceitam a mesma requisição. 1. O Lacuna TSA valida a requisição: o content type, as credenciais, a codificação, a política pedida e o hash. Se algo falhar, responde sem carimbo ([veja as falhas](https://docs.lacunasoftware.com/articles/tsa#falhas)). 1. Monta o `TSTInfo`, com os [campos abaixo](https://docs.lacunasoftware.com/articles/tsa#conteudo): o OID da PCT, o hash, um número de série, o `genTime` em UTC, a precisão, `ordering` falso e o `nonce`. 1. Assina o `TSTInfo` com a chave do SCT, cujo certificado ICP-Brasil tem o uso estendido de chave `id-kp-timeStamping`. 1. Inclui o alvará nos atributos assinados do carimbo. 1. Devolve a resposta (TSR, um `TimeStampResp`) com o status *granted* e o carimbo, com o header `Content-Type: application/timestamp-response`. 1. Sua aplicação verifica o carimbo: o hash e o `nonce` são os que ela enviou, a assinatura é válida, a cadeia do certificado do SCT chega à AC Raiz da ICP-Brasil e o alvará era válido no `genTime`. Depois guarda o carimbo, ou o inclui na assinatura que ele carimba. Fora da ICP-Brasil o fluxo é o mesmo, sem o SAS e sem o alvará: o Lacuna TSA obtém a hora dos servidores NTP da seção `Ntp` ou do relógio do sistema (veja [Configuração de sincronização com NTP](https://docs.lacunasoftware.com/articles/tsa/on-premises/configure-ntp)), e o carimbo segue a política padrão ou a configurada em `Tsa:PolicyId`. ## O que o carimbo contém | Campo do `TSTInfo` | Valor | |---|---| | `version` | `1` | | `policy` | `Tsa:PolicyId`; por padrão, `1.3.6.1.4.1.46332.4.1` | | `messageImprint` | Copiado da requisição: o algoritmo de hash e o hash. Vale qualquer algoritmo que o cliente escolher, como SHA-256 ou SHA-512 | | `serialNumber` | Um número aleatório de 128 bits, único para cada carimbo | | `genTime` | A hora da emissão, em UTC, com frações de segundo | | `accuracy` | 1 segundo | | `ordering` | `false` | | `nonce` | Copiado da requisição, quando presente | | `tsa` | O nome do titular (*subject*) do certificado da TSA | | `extensions` | Nenhuma | O `TSTInfo` é assinado como um `SignedData` CMS, com SHA-256. Os atributos assinados são `content-type`, `message-digest` e `signing-certificate-v2`, além de `signer-attributes` quando há um certificado de atributo em `Tsa:Tac`. Não há o atributo `signing-time`: a hora é o `genTime`. O `SignedData` sempre inclui o certificado da TSA, mas não o restante da cadeia. ## Como solicitar um carimbo de tempo As bibliotecas de assinatura em geral montam a requisição e leem a resposta por você: basta informar o endereço da TSA. Para testar um servidor manualmente, use o OpenSSL e o curl: ```bash openssl ts -query -data documento.pdf -sha256 -cert -out requisicao.tsq ``` ```bash curl -H "Content-Type: application/timestamp-query" --data-binary @requisicao.tsq -o resposta.tsr https://endereco-da-sua-tsa/ ``` ```bash openssl ts -reply -in resposta.tsr -text ``` Se a instância exigir autenticação, acrescente `-u USUARIO:SENHA` (`Basic`) ou `-H "Authorization: Bearer SEU_TOKEN"` ao comando do curl. ## Falhas | Situação | Resposta | |---|---| | O content type não é `application/timestamp-query` | HTTP 400. Para aceitar outros content types, defina `Tsa:CheckRequestType` como `False` | | Credenciais ausentes ou erradas, ou usuário desativado | `TimeStampResp` com status *rejection* e `failInfo` `notAuthorized` | | A requisição não pode ser decodificada | `TimeStampResp` sem carimbo, com `failInfo` `badRequest` | | `reqPolicy` diferente de `Tsa:PolicyId` | `TimeStampResp` sem carimbo, com `failInfo` `unacceptedPolicy` | | A requisição não traz o hash (`messageImprint`) | `TimeStampResp` sem carimbo, com `failInfo` `badMessageCheck` | | O carimbo não pôde ser assinado | `TimeStampResp` sem carimbo, com `failInfo` `systemFailure` | Desde a versão 1.2.1, uma requisição cujo `reqPolicy` não seja o valor de `Tsa:PolicyId` é recusada. Se os seus clientes enviam `reqPolicy`, configure `Tsa:PolicyId`, mesmo que com o OID padrão `1.3.6.1.4.1.46332.4.1`, para que as requisições correspondam. ## Configurações Estas configurações definem os carimbos emitidos. O formato é o mesmo das configurações de [autenticação](https://docs.lacunasoftware.com/articles/tsa/on-premises/configure-auth) e de [NTP](https://docs.lacunasoftware.com/articles/tsa/on-premises/configure-ntp): seções no arquivo `.conf` ou variáveis de ambiente como `Tsa__PolicyId`. | Configuração | Descrição | |---|---| | `Tsa:PolicyId` | OID da política dos carimbos. Padrão: `1.3.6.1.4.1.46332.4.1` | | `Tsa:Tac` | Certificado de atributo incluído em todo carimbo, em Base64, como o alvará da ICP-Brasil. Padrão: nenhum | | `Tsa:CheckRequestType` | Defina como `False` para aceitar requisições sem o content type `application/timestamp-query`. Padrão: `True` | | `KeyStore:Type` | Onde fica a chave da TSA: `Pkcs12` ou `Amplia` | | `KeyStore:Pkcs12Content`, `KeyStore:Pkcs12Password` | Com `Pkcs12`: o arquivo PKCS #12, em Base64, e a senha dele | | `KeyStore:KeyId`, `KeyStore:CertificateId` | Com `Amplia`: o ID da chave e o do certificado da TSA no Amplia | | `KeyStore:Certificate` | Com `Amplia`, quando o certificado da TSA não foi emitido pela mesma assinatura do Amplia que guarda a chave: o certificado, em Base64 | | `Amplia:Endpoint`, `Amplia:ApiKey` | Com `Amplia`: o endereço da instância do Amplia e a chave de API de uma aplicação com o papel **Gerente** (*Manager*) | Exemplo (arquivo `.conf`) para um SCT da ICP-Brasil com a chave no Amplia: ```ini [Tsa] PolicyId=2.16.76.1.6.n Tac=BASE64_DO_ALVARA [KeyStore] Type=Amplia KeyId=00000000-0000-0000-0000-000000000000 CertificateId=00000000-0000-0000-0000-000000000000 [Amplia] Endpoint=https://endereco-do-seu-amplia/ ApiKey=SUA_CHAVE_DE_API ``` ## Veja também * [Lacuna TSA *on premises*](https://docs.lacunasoftware.com/articles/tsa/on-premises) * [Configuração de sincronização com NTP](https://docs.lacunasoftware.com/articles/tsa/on-premises/configure-ntp) * [Configuração de autenticação](https://docs.lacunasoftware.com/articles/tsa/on-premises/configure-auth) * [OIDs da Lacuna Software](https://docs.lacunasoftware.com/articles/asn1) * [Histórico de versões](https://docs.lacunasoftware.com/articles/tsa/changelog)