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.

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: <SiteUrl>/tsp-callback, por exemplo https://assinador.patorum.com/tsp-callback.

2. Cadastre o aplicativo no lugar certo para cada provedor:

   Provedor	Onde cadastrar
   BirdID, SafeID e VIDaaS	Cadastro de aplicativos PSC da Lacuna
   SerproID	Formulário de cadastro do Serpro
   Outros provedores	Fale com o suporte do provedor

3. 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.

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

"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.

3. Reinicie e teste

1. Reinicie a aplicação.
2. Crie um documento para um signatário que tem certificado em um dos provedores configurados.
3. 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:

Error calling trust service '<provedor>' 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 <SiteUrl>/api/csc/callback.

2. Anote o ClientId, o ClientSecret e a URL base da API CSC do provedor.

3. Na seção Csc, defina Enabled como true e crie uma subseção em Services para cada provedor:

   "Csc": {
     "Enabled": true,
     "Services": {
       "MeuProvedor": {
         "FriendlyName": "Meu provedor",
         "Endpoint": "https://csc.provedor.com.br/",
         "ClientId": "...",
         "ClientSecret": "...",
         "BadgeUrl": "https://provedor.com.br/selo.png"
       }
     }
   }

4. 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.

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 <SiteUrl>/tsp-callback (PSC) ou <SiteUrl>/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
• Verificando os logs (Linux)