--- title: "Certificado em nuvem" description: "Como habilitar certificados em nuvem no Signer on-premises: cadastro do aplicativo no provedor (PSC ou CSC), URI de redirecionamento, ClientId e ClientSecret, descoberta e erros comuns." canonical: "https://docs.lacunasoftware.com/articles/signer/on-premises/certificado-em-nuvem" locale: "pt-BR" product: "Signer" last_updated: "2026-10-22" --- # Certificado em nuvem O Signer pode assinar com certificados guardados em um provedor na nuvem, sem token ou cartão no computador do usuário. Esta página mostra como ligar essa integração em uma instância on-premises. O Signer fala com dois tipos de provedor: | Tipo | O que é | Seção de configuração | |---|---|---| | PSC | Prestador de Serviço de Confiança (PSC) da ICP-Brasil, por exemplo BirdID, SafeID, VIDaaS e NeoID | `TrustServices` | | CSC | Provedor que segue o padrão *Cloud Signature Consortium* (CSC) | `Csc` | > **Observação** > > Se a seção `Cloudhub` estiver configurada, o Cloudhub fornece a lista de provedores. Nesse caso, o Signer não usa os > provedores da seção `TrustServices`. Veja as [configurações do Cloudhub](https://docs.lacunasoftware.com/articles/signer/on-premises/settings#configurações-cloudhub-v300). ## Provedores PSC ### 1. Cadastre o aplicativo no provedor Cada provedor exige o cadastro de um aplicativo. O cadastro gera um `ClientId` e um `ClientSecret`. 1. Informe estes dados no cadastro: * Nome: o nome da sua instância, por exemplo *Assinador Patorum*. * Descrição: uma frase sobre o portal, por exemplo *Portal de assinaturas da Patorum*. * E-mail de suporte: o endereço que vai receber os avisos do provedor. * URI de redirecionamento: `/tsp-callback`, por exemplo `https://assinador.patorum.com/tsp-callback`. 1. Cadastre o aplicativo no lugar certo para cada provedor: | Provedor | Onde cadastrar | |---|---| | BirdID, SafeID e VIDaaS | [Cadastro de aplicativos PSC da Lacuna](https://demos.lacunasoftware.com/pt/tsp-app-registration) | | SerproID | [Formulário de cadastro do Serpro](https://serproid.serpro.gov.br/manual-integracao/manutencao/formulario-cadastro-aplicacao/) | | Outros provedores | Fale com o suporte do provedor | 1. Anote o `ClientId` e o `ClientSecret` de cada provedor. > **Aviso** > > A URI de redirecionamento cadastrada deve ser igual, caractere por caractere, à URI que o Signer envia. O Signer > monta a URI com o valor de `General:SiteUrl` seguido de `tsp-callback`. Se o `SiteUrl` tiver um caminho (por > exemplo `https://patorum.com/assinador/`), termine o valor com `/`. Sem a barra final, o Signer descarta o último > segmento do caminho. > **Dica** > > Cada ambiente (homologação e produção) tem um domínio próprio e, portanto, uma URI de redirecionamento própria. > Cadastre a URI de cada ambiente no provedor. Se o provedor recusar uma URI que já existe em outro aplicativo, edite > o aplicativo existente em vez de criar um novo. ### 2. Configure o Signer Na seção `TrustServices`, habilite a integração e informe as credenciais de cada provedor. O nome da subseção dentro de `Services` é o nome do provedor (`BirdID`, `SafeID`, `VIDaaS`, `NeoID` etc.). Informe só os provedores que você vai usar. ```json "TrustServices": { "Enabled": true, "Services": { "BirdID": { "ClientId": "...", "ClientSecret": "..." }, "VIDaaS": { "ClientId": "...", "ClientSecret": "..." } } } ``` Em variáveis de ambiente (Docker ou Azure App Service), use `__` no lugar de `:`. Por exemplo: `TrustServices__Services__BirdID__ClientId`. O Signer já conhece o endpoint de produção dos provedores mais comuns. Para um provedor sem endpoint padrão, ou para usar o ambiente de homologação de um provedor, informe também `Endpoint`, `Provider` e `BadgeUrl` com os valores que o provedor fornece. Exemplo: ```json "SerproID": { "ClientId": "...", "ClientSecret": "...", "Endpoint": "https://neoid.estaleiro.serpro.gov.br/smartcert-api/", "Provider": "SERPRO", "BadgeUrl": "https://cdn.lacunasoftware.com/img/psc/serproid.png" } ``` A lista completa de chaves está em [configurações *TrustServices*](https://docs.lacunasoftware.com/articles/signer/on-premises/settings#configurações-trustservices-certificados-em-nuvem-v1110). ### 3. Reinicie e teste 1. Reinicie a aplicação. 1. Crie um documento para um signatário que tem certificado em um dos provedores configurados. 1. Abra o documento como esse signatário e escolha assinar com certificado. O provedor aparece na lista de certificados em nuvem. ### Como a descoberta funciona A descoberta é a consulta que o Signer faz para saber em quais provedores o signatário tem certificado. * Com `DiscoveryEnabled` em `true` (padrão), o Signer consulta só os provedores configurados em `Services`, com o CPF (ou CNPJ) do signatário. A tela mostra só os provedores que responderam que têm um certificado para esse identificador. * Se nenhum provedor tiver certificado para o signatário, a tela não mostra nenhum provedor em nuvem. * Se o signatário não tiver identificador, o Signer não faz a descoberta e não mostra nenhum provedor em nuvem. * Com `DiscoveryEnabled` em `false`, a tela mostra todos os provedores configurados para todos os usuários, com ou sem identificador. Se um provedor falhar na descoberta (credencial inválida, timeout ou endpoint ausente), o Signer ignora esse provedor e registra no log uma mensagem como esta: ```text Error calling trust service '' to discover certificates for ... (ignoring service) ``` O usuário não vê erro. O provedor só some da lista. O tempo máximo de espera de cada provedor é `TrustServices:DiscoveryTimeoutSeconds` (padrão: 10 segundos). > **Aviso** > > Antes de definir `DiscoveryEnabled` como `false`, remova os provedores sem endpoint válido. Nesse modo, o Signer > prepara a autorização de todos os provedores de uma vez. Um provedor sem endpoint faz a lista inteira falhar. ## Provedores CSC 1. Cadastre o aplicativo no provedor CSC com a URI de redirecionamento `/api/csc/callback`. 1. Anote o `ClientId`, o `ClientSecret` e a URL base da API CSC do provedor. 1. Na seção `Csc`, defina `Enabled` como `true` e crie uma subseção em `Services` para cada provedor: ```json "Csc": { "Enabled": true, "Services": { "MeuProvedor": { "FriendlyName": "Meu provedor", "Endpoint": "https://csc.provedor.com.br/", "ClientId": "...", "ClientSecret": "...", "BadgeUrl": "https://provedor.com.br/selo.png" } } } ``` 1. Reinicie a aplicação. Os provedores CSC não passam pela descoberta: a tela de assinatura mostra todos os provedores configurados. As demais chaves (por exemplo, a fixação do certificado do servidor) estão em [configurações *Csc*](https://docs.lacunasoftware.com/articles/signer/on-premises/settings#csc). ## Erros comuns | Sintoma | Causa provável | O que fazer | |---|---|---| | O provedor recusa o login com erro de `redirect_uri` | A URI cadastrada no provedor é diferente da URI que o Signer envia | Compare a URI cadastrada com `/tsp-callback` (PSC) ou `/api/csc/callback` (CSC). Verifique protocolo, domínio, caminho e barra final | | Nenhum provedor em nuvem aparece | `TrustServices:Enabled` está em `false`, o signatário não tem certificado nos provedores configurados ou todos os provedores falharam na descoberta | Verifique a configuração. Procure no log a mensagem `(ignoring service)` | | Um provedor aparece para um usuário e não para outro | Comportamento esperado da descoberta | O provedor só aparece para quem tem certificado nele | | Um provedor configurado nunca aparece | Credencial inválida, nome de provedor que o Signer não conhece sem `Endpoint`, ou endpoint inacessível a partir do servidor | Procure no log a mensagem `(ignoring service)` com o nome do provedor. Verifique se o servidor do Signer acessa o endpoint do provedor | | Os provedores da seção `TrustServices` não aparecem, mas o Cloudhub está configurado | O Cloudhub tem precedência | Cadastre os provedores no Cloudhub ou remova a seção `Cloudhub` | ## Veja também * [Configurações do Signer](https://docs.lacunasoftware.com/articles/signer/on-premises/settings) * [Verificando os logs (Linux)](https://docs.lacunasoftware.com/articles/signer/on-premises/linux/troubleshoot/check-logs)