Certificado TLS/SSL sem avisos no navegador para demos no Windows Server 2022 e IIS

Quer evitar o constrangimento do aviso de “conexão não segura” em demos com IIS, API REST e SQL Server no Windows Server 2022? Este guia prático mostra, com passos claros, como conseguir navegação segura sem pop‑ups, dentro e fora de ambientes controlados.

Índice

Visão geral do problema

O cenário é típico de equipes de pré‑vendas e profissionais de serviços: um servidor Windows Server 2022 em workgroup hospeda um site no IIS, uma API REST e o SQL Server. As demos podem ocorrer em diferentes clientes, redes e dispositivos — laptops do seu domínio, máquinas do domínio do cliente e smartphones conectados ao Wi‑Fi local. O desejo é legítimo: usar TLS/SSL com um certificado que não gere alertas nos navegadores dos visitantes.

A pergunta central costuma surgir: “basta criar um certificado autoassinado?” A resposta direta é não. Os navegadores só confiam automaticamente em certificados que encadeiam até uma Autoridade Certificadora (AC) reconhecida e incluída na loja de raiz do dispositivo. Um certificado autoassinado é, por definição, desconhecido para o dispositivo do cliente e, portanto, gerará aviso, a menos que você instale sua raiz manualmente em cada dispositivo.

Resposta curta e objetiva

Não existe certificado autoassinado universalmente aceito por navegadores em dispositivos que você não controla. Para eliminar o aviso sem pedir nada ao cliente, em demos “em qualquer lugar”, use um certificado emitido por uma AC pública para um FQDN sob um domínio seu e garanta que esse nome resolva para o IP do servidor no local da demonstração. Se o ambiente for totalmente controlado, é viável utilizar uma AC privada e distribuir sua raiz aos dispositivos participantes.

Caminhos viáveis

Cenário universal com autoridade pública

Este é o caminho recomendado para demos em ambientes variados, onde você não pode exigir instalação de certificados nos dispositivos dos convidados.

Use um FQDN sob seu domínio, por exemplo, demo.suaempresa.com. Evite nomes locais (como srv01 ou *.local) e evite IPs na URL.
Emita o certificado em uma AC pública (por exemplo, via ACME/Let’s Encrypt ou comercial) e leve um PFX com a cadeia completa para instalar no IIS.
Garanta a resolução DNS do FQDN para o IP do servidor no local da demo. Isso pode ser feito com split‑DNS na rede do evento, DNS local, um pequeno appliance de DNS ou, em último caso, via ajustes temporários de hosts em máquinas que você controla.
Vincule o certificado no IIS no binding https do site, usando SNI quando houver mais de um host no mesmo IP.
Se a API REST não estiver no IIS, padronize o certificado no front‑end (por exemplo, um reverse proxy no próprio IIS, ARR ou outro gateway) para que clientes externos vejam a mesma identidade do servidor.

Vantagens: funciona “sem conversa” em praticamente todos os dispositivos. Desafios: exige domínio próprio e um processo de renovação (ex.: 90 dias em ACME).

Cenário controlado com autoridade privada

Este caminho funciona muito bem em redes internas, treinamentos e PoCs com público limitado, quando você pode instalar a raiz da sua AC privada em cada dispositivo participante.

Crie sua AC privada (Windows AD CS em modo Standalone, step‑ca ou OpenSSL).
Distribua e confie a raiz em Windows, macOS, iOS e Android. Nos celulares, é comum instalar um perfil e ativar confiança explícita.
Emita um certificado de servidor com Subject Alternative Name para todos os nomes que serão usados na demo.
Vincule no IIS e nos demais serviços que expõem TLS (API, SQL Server se aplicável).
Remova a raiz dos dispositivos do cliente após a sessão, quando a confiança temporária não fizer mais sentido.

Vantagens: independe de Internet e de domínio público. Desafios: demanda logística de instalação e não escala para demos abertas.

Tabela de decisão rápida

Situação	Recomendação	Por quê
Demos em clientes variados, dispositivos heterogêneos	AC pública + FQDN seu + split‑DNS	Elimina avisos sem tocar nos dispositivos do cliente
Laboratório interno, público controlado	AC privada + distribuição da raiz	Funciona sem Internet; controle total da confiança
Serviços múltiplos no mesmo host	Certificado com SAN abrangente ou wildcard	Simplifica gerenciamento e bindings
Servidor sem acesso à Internet	Emissão antecipada com DNS‑01 e transporte do PFX	Evita expor portas e permite preparar tudo antes

Boas práticas universais

Inclua SAN no certificado. Apenas Common Name não basta para navegadores modernos.
Algoritmo e força: RSA 2048 ou superior, SHA‑256. Use EKU com Server Authentication.
Cadeia completa: sempre inclua os intermediários. Um PFX com cadeia evita erros de chain.
Correspondência de nome: o host acessado precisa estar no SAN do certificado.
Evite IPs na URL. Prefira nomes DNS. Certificados com IP nos SANs têm suporte limitado e complicam a vida em celulares.
Vigência compatível com a política da AC. Em AC pública, não extrapole limites de validade.
Split‑DNS no local do evento: garanta que demo.suaempresa.com resolva para o IP do servidor na rede onde a demo ocorrerá.
Proteja chaves privadas: armazene PFX com senha forte, limite acesso e apague cópias após a demo.

Passo a passo com autoridade pública

Preparação do domínio e do nome

Escolha um FQDN sob seu domínio, por exemplo demo.suaempresa.com. Reserve também subdomínios para API, se desejar, como api.demo.suaempresa.com.
Crie registros DNS públicos conforme o método de validação da AC. Para servidores que não estarão acessíveis de fora, prefira DNS‑01 e emita o certificado antes da visita ao cliente.

Emissão com ACME por DNS

Com o desafio DNS‑01, você comprova domínio adicionando um registro TXT no DNS público. Assim, o servidor de demo não precisa estar exposto à Internet. Depois de emitido, exporte o PFX contendo a cadeia intermediária.

Dica prática: mantenha um pipeline de renovação agendada. Se sua ferramenta ACME gerar PEMs, converta para PFX no Windows:

# Exemplo de conversão PEM -&gt; PFX no Windows com PowerShell e OpenSSL instalado
Ajuste caminhos conforme seu ambiente
openssl pkcs12 -export -out C:\Certs\demo.pfx -inkey C:\Certs\privkey.pem -in C:\Certs\fullchain.pem -passout pass:SuaSenhaForte

Instalação e vinculação no IIS

Importe o PFX no armazenamento Local Computer > Personal com senha.
No IIS Manager, em Bindings do site, adicione https com o host demo.suaempresa.com e selecione o certificado correspondente. Ative SNI quando houver múltiplos hosts no mesmo IP.
Certifique-se de que a cadeia aparece completa nas propriedades do certificado no MMC.

Garantia de resolução de nome na rede do cliente

O FQDN precisa apontar para o IP do seu servidor no local da demo. Você pode:

Configurar split‑DNS no roteador/servidor DHCP local;
Usar um pequeno servidor DNS local temporário (por exemplo, em uma VM que você leva);
Ajustar hosts apenas em máquinas sob seu controle (não funciona para celulares de convidados).

Validação rápida

# Windows PowerShell
Test-NetConnection demo.suaempresa.com -Port 443

Inspeção do certificado no Windows

certutil -urlfetch -verify "Cert:\LocalMachine\My<THUMBPRINT>"

Checagem de SNI e cadeia com OpenSSL (em uma máquina sua)

openssl s\_client -connect demo.suaempresa.com:443 -servername demo.suaempresa.com -showcerts

Passo a passo com autoridade privada

Este método cria uma cadeia de confiança local (raiz e, opcionalmente, uma emissora) e emite certificados de servidor assinados por ela. O ponto crucial é a distribuição segura da raiz a todos os dispositivos que participarão da demo.

Criação de raiz e emissora com PowerShell

O script abaixo cria uma raiz, uma emissora e um certificado de servidor compatível com navegadores e SQL Server, incluindo SANs. Ajuste nomes, validade e caminhos conforme sua realidade.

# Executar em PowerShell elevado no Windows Server 2022

Cria a raiz da AC (não inclui EKU; uso exclusivo para assinar)

\$root = New-SelfSignedCertificate `  -Type Custom`
-KeyUsage CertSign, CRLSign `  -KeyExportPolicy Exportable`
-KeySpec Signature `  -Subject "CN=Demo Root CA"`
-CertStoreLocation "Cert:\LocalMachine\My" `  -HashAlgorithm sha256`
-KeyLength 4096 \`
-TextExtension @("2.5.29.19={text}CA=true&pathlength=1")

Cria a emissora subordinada (opcional, mas recomendado)

\$issuing = New-SelfSignedCertificate `  -Type Custom`
-KeyUsage CertSign, CRLSign, DigitalSignature `  -KeyExportPolicy Exportable`
-KeySpec Signature `  -Subject "CN=Demo Issuing CA"`
-CertStoreLocation "Cert:\LocalMachine\My" `  -HashAlgorithm sha256`
-KeyLength 4096 `  -Signer $root`
-TextExtension @("2.5.29.19={text}CA=true&pathlength=0")

Emite o certificado de servidor com SANs

\$dns = @("demo.suaempresa.com","api.demo.suaempresa.com")
\$server = New-SelfSignedCertificate `  -DnsName $dns`
-KeyExportPolicy Exportable `  -KeySpec KeyExchange`
-Subject "CN=demo.suaempresa.com" `  -CertStoreLocation "Cert:\LocalMachine\My"`
-Signer \$issuing `  -NotAfter (Get-Date).AddYears(1)`
-HashAlgorithm sha256 \`
-TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.1")  # EKU Server Authentication

Exporta PFX com a cadeia intermediária

\$pwd = ConvertTo-SecureString 'SenhaBemForte' -AsPlainText -Force
Export-PfxCertificate -Cert \$server -FilePath C:\Certs\demo.pfx -Password \$pwd -ChainOption BuildChain

Exporta a raiz (para distribuição aos clientes)

Export-Certificate -Cert \$root -FilePath C:\Certs\DemoRootCA.cer

Observações importantes:

Evite usar a raiz diretamente para assinar servidores. Prefira a emissora subordinada. Mantém a raiz mais protegida.
Use KeySpec KeyExchange no certificado de servidor para compatibilidade com SQL Server e sistemas legados.
Mantenha a validade do servidor razoável (por exemplo, um ano). Para ambientes temporários, validades curtas reduzem risco.

Distribuição da raiz nos clientes

Plataforma	Como instalar e confiar	Observações
Windows	Abra o Microsoft Management Console com o snap‑in de Certificates para o Computador Local e importe a raiz em Trusted Root Certification Authorities.	Usuários sem privilégio admin não conseguem instalar na loja do computador. Planeje acesso.
macOS	Abra o Keychain Access, importe a raiz no System e marque como Always Trust para SSL.	É necessário informar a senha de administrador.
iOS	Instale um perfil com a raiz e, depois, ative a confiança total em Ajustes > Geral > Sobre > Ajustes de Confiança de Certificado.	Sem ativar a confiança, o Safari segue bloqueando.
Android	Instale a CA em Configurações > Segurança > Instalar do armazenamento.	Alguns apps não confiarão em CAs do usuário por políticas modernas. Navegadores costumam respeitar.

Para agilizar em um laboratório, hospede temporariamente o arquivo DemoRootCA.cer no próprio servidor por http (sem TLS) apenas dentro da rede isolada do evento, e forneça um QR Code para download local. Ao final, remova o arquivo e invalide o acesso.

Emissão com AD CS Standalone

Se preferir, instale a função Active Directory Certificate Services em modo Standalone no Windows Server em workgroup. A sequência típica é:

Adicionar o serviço de função Certification Authority e configurar uma Standalone Root CA ou uma Issuing CA.
Gerar um CSR para o servidor e usar certreq para solicitar e, depois, aceitar o certificado emitido.

Modelo de INF para certreq com SAN:

[Version]
Signature="$Windows NT$"

\[NewRequest]
Subject = "CN=demo.suaempresa.com"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
HashAlgorithm = sha256
SMIME = FALSE
RequestType = PKCS10

\[Extensions]
; EKU Server Authentication
2.5.29.37 = "{text}"
continue = "1.3.6.1.5.5.7.3.1"

; Subject Alternative Name
2.5.29.17 = "{text}"
continue = "dns=demo.suaempresa.com&dns=api.demo.suaempresa.com"

# Gera o CSR
certreq -new C:\Req\server.inf C:\Req\server.req

Submete e recebe o certificado da AC privada
certreq -submit C:\Req\server.req C:\Req\server.cer

Instala no repositório local e cria o PFX se desejar
certreq -accept C:\Req\server.cer

Integração com IIS, API REST e SQL Server

Vinculação no IIS

No site desejado, crie ou edite o binding https, informe o host name e selecione o certificado correto.
Ative SNI quando houver múltiplos hosts no mesmo IP para que cada host receba seu certificado próprio.
Se utilizar um reverse proxy no IIS com ARR, termine TLS no IIS e encaminhe as requisições em http para o serviço interno (offload de TLS), ou faça re‑encrypt end‑to‑end se necessário.

Protegendo uma API REST fora do IIS

Para serviços em Kestrel, Http.sys ou containers:

Recomenda‑se terminar TLS em um front‑end (IIS com ARR, Nginx, HAProxy) e manter o certificado unificado.
Se expor TLS direto do processo, garanta que o nome usado pelos clientes exista no SAN do certificado e que a cadeia esteja instalada no store correto.

Configurando TLS no SQL Server

Instale o certificado em Local Computer > Personal com chave privada acessível ao serviço do SQL Server.
Abra o SQL Server Configuration Manager, vá em SQL Server Network Configuration > Protocols, acesse as propriedades, guia Certificate, selecione o certificado cujo SAN ou CN corresponde ao nome que os clientes usam para conectar.
Opcionalmente, habilite Force Encryption e reinicie o serviço.
Nos clientes, use Encrypt=True; TrustServerCertificate=False; na connection string. Com um certificado válido e nome correspondente, a conexão será estabelecida sem aviso.

Dica de teste rápido:

# Teste de conexão criptografada
sqlcmd -S demo.suaempresa.com -N -l 30

Verificações e solução de problemas

Erro de nome: o navegador indica que o nome não corresponde. Verifique se o SAN inclui exatamente o host acessado.
Cadeia incompleta: alguns clientes exibem erro de emissor desconhecido, apesar de a raiz ser confiável. Quase sempre é intermediário faltando. Reexporte seu PFX com a cadeia completa.
Chave inacessível no IIS: se o certificado não aparece na lista, importe o PFX em Local Computer > Personal e confira as permissões da chave privada.
Android não confia: apps modernos podem rejeitar CAs do usuário. Em navegadores, em geral funciona. Para apps, use AC pública ou política de network security config.
Navegador ainda alerta após instalar raiz no iOS: é preciso ativar confiança total manualmente nas configurações do aparelho.
Conflitos de SNI: dois bindings com o mesmo host e porta podem causar seleção de certificado inesperada. Revise bindings e host headers.

Checklist para o dia da demo

Certificado válido para o FQDN, com cadeia completa.
DNS local apontando o FQDN para o IP do servidor na rede do cliente.
Porta quatro quatro três liberada entre clientes e servidor.
Binding https no IIS com SNI, se aplicável.
Se usar AC privada, raiz instalada e confiável em todos os dispositivos participantes.
Testes prévios em um laptop de convidado e em um smartphone para validar experiência real.
Plano de remoção da raiz ao término, quando usar AC privada em ambiente de cliente.

Dicas para redes desafiadoras

Captive portals: conecte‑se primeiro ao Wi‑Fi, autentique no portal em http, e só depois mude o DNS local do seu dispositivo para o DNS de split‑horizon da demo.
Ambiente sem DHCP gerenciável: leve um travel router próprio para isolar a rede da demo, com DNS local configurado.
Sem domínio público: use AC privada e distribuição de raiz, mas alinhe com antecedência o procedimento de instalação com o cliente.

Perguntas frequentes

Posso usar um certificado autoassinado diretamente no servidor e esperar que não haja alertas?
Não, a menos que você instale manualmente a raiz que assina esse certificado em cada dispositivo que acessará a demo.

Um wildcard público resolve para vários serviços?
Sim, um *.demo.suaempresa.com cobre subdomínios como api.demo.suaempresa.com. Ainda assim, evite usá‑lo em produção sem política adequada de emissão e rotação, pois amplia o impacto de uma chave comprometida.

Por que evitar IP no certificado?
Além de ser pouco amigável, nem todos os clientes dão suporte consistente a IPs em SANs, e você perde a flexibilidade de reendereçar serviços via DNS.

Posso desabilitar verificações no navegador para “dar certo”?
Não é recomendável. Pede passos manuais, passa má impressão e reduz segurança. O objetivo aqui é just works.

Como renovo certificados ACME se o servidor não tem Internet?
Planeje emissões por DNS‑01 antecipadas e leve o PFX renovado. Automatize em uma máquina com acesso ao DNS público da sua zona.

Modelo de plano prático por cenário

Plano para demos em clientes variados

Registrar demo.suaempresa.com e planejar SANs adicionais conforme necessário.
Automatizar emissão ACME por DNS‑01 antes de cada ciclo de demos.
Exportar PFX com cadeia; guardar em C:\Certs com senha forte.
No local da demo, prover DNS local que resolve demo.suaempresa.com para o IP do servidor.
Importar o PFX, vincular no IIS, testar SNI e realizar smoke tests do site, API e SQL.

Plano para laboratório interno controlado

Implantar AC privada com raiz e emissora.
Emitir certificados de servidor com SAN para todos os hosts do laboratório.
Distribuir e confiar a raiz nos dispositivos do time por GPO, MDM ou instalação assistida.
Padronizar cadeia e nomes DNS em todos os serviços, incluindo SQL Server.

Erros comuns e como evitar

Usar apenas CN e esquecer SAN. Resultado: aviso de nome inválido. Sempre inclua SANs.
Não incluir intermediários no PFX. Resultado: alguns clientes falham na validação da cadeia.
Vincular https sem SNI quando há mais de um host no mesmo IP. Resultado: certificado “troca” conforme o site.
Emitir para um nome e acessar por outro (ex.: emitir para demo.suaempresa.com e acessar por srv01). Mantenha consistência.
Chave privada inacessível ao serviço. Confira permissões e reimporte o PFX se necessário.

Resumo executivo

Para demos em qualquer ambiente, a rota mais confiável é certificado público para um FQDN sob seu domínio, com split‑DNS no local. Em ambientes controlados, uma AC privada resolve, desde que você instale a raiz nos dispositivos participantes. Em todos os casos, cuide dos SANs, da cadeia completa e dos bindings no IIS. Assim você elimina os avisos, demonstra profissionalismo e mantém a segurança em dia.