Minha empresa distribui um Windows Installer para um produto baseado em servidor. De acordo com as melhores práticas, ele é assinado usando um certificado. De acordo com o conselho da Microsoft , usamos um certificado de assinatura de código GlobalSign , que a Microsoft afirma ser reconhecido por padrão por todas as versões do Windows Server.
Agora, tudo isso funciona bem, a menos que um servidor tenha sido configurado com Diretiva de Grupo: Configuração do Computador/Modelos Administrativos/Sistema/Gerenciamento de Comunicação na Internet/Configurações de Comunicação na Internet/Desativar Atualização Automática do Certificado Raiz como Ativado .
Descobrimos que um de nossos primeiros testadores beta estava sendo executado com essa configuração, resultando no seguinte erro durante a instalação
Um arquivo necessário não pode ser instalado porque o arquivo cabinet [caminho longo para o arquivo cab] tem uma assinatura digital inválida. Isso pode indicar que o arquivo de gabinete está corrompido.
Nós escrevemos isso como uma esquisitice, afinal ninguém foi capaz de explicar por que o sistema foi configurado assim. No entanto, agora que o software está disponível para uso geral, parece que um dígito duplo (porcentagem) de nossos clientes está configurado com essa configuração e ninguém sabe por quê. Muitos relutam em mudar a configuração.
Escrevemos um artigo da base de conhecimento para nossos clientes, mas realmente não queremos que o problema aconteça, pois realmente nos preocupamos com a experiência do cliente.
Algumas coisas que notamos ao investigar isso:
- Uma nova instalação do Windows Server não mostra o certificado Globalsign na lista de autoridades raiz confiáveis.
- Com o Windows Server não conectado à Internet, a instalação do nosso software funciona bem. Ao final da instalação está presente o certificado Globalsign (não importado por nós). No fundo, o Windows aparece para instalá-lo de forma transparente no primeiro uso.
Então, aqui está a minha pergunta novamente. Por que é tão comum desabilitar a atualização de certificados raiz? Quais são os possíveis efeitos colaterais de habilitar as atualizações novamente? Quero ter certeza de que podemos fornecer aos nossos clientes a orientação adequada.
No final de 2012 / início de 2013, houve um problema com as atualizações automáticas do certificado raiz. A correção temporária foi desativar as atualizações automáticas, portanto, em parte, esse problema é histórico.
A outra causa é o programa Trusted Root Certificate e Root Certificate Distribution, que (parafraseando Microsoft )...
Até aí, tudo bem, mas depois...
Quando isso acontece, pode parecer que os certificados estão sendo adicionados automaticamente ao armazenamento raiz. Tudo isso deixa alguns administradores de sistema nervosos, pois você não pode remover uma CA 'ruim' das ferramentas de gerenciamento de certificados porque elas não estão lá para remover ...
Na verdade, existem maneiras de fazer o Windows baixar a lista completa para que eles possam editá-la como quiserem, mas é comum apenas bloquear as atualizações. Um grande número de administradores de sistema não entende criptografia ou segurança (geralmente), então eles seguem a sabedoria recebida (correta ou não) sem questionar e não gostam de fazer alterações em coisas que envolvem segurança que eles não entendem completamente acreditando ser alguma arte negra.
O componente Automatic Root Certificates Update foi projetado para verificar automaticamente a lista de autoridades confiáveis no site do Microsoft Windows Update. Especificamente, há uma lista de autoridades de certificação raiz (CAs) confiáveis armazenadas no computador local. Quando um aplicativo recebe um certificado emitido por uma CA, ele verifica a cópia local da lista de CA raiz confiável. Se o certificado não estiver na lista, o componente Automatic Root Certificates Update entrará em contato com o site Microsoft Windows Update para verificar se há uma atualização disponível. Se a CA tiver sido adicionada à lista de CAs confiáveis da Microsoft, seu certificado será adicionado automaticamente ao armazenamento de certificados confiáveis no computador.
A resposta curta é provavelmente que se trata de controle. Se você deseja controlar quais CAs raiz são confiáveis (em vez de usar esse recurso e permitir que a Microsoft faça isso por você), é mais fácil e seguro criar uma lista de CAs raiz em que deseja confiar, distribua-as para seus computadores de domínio e, em seguida, bloqueie essa lista. Como as alterações na lista de CAs raiz em que uma organização deseja confiar seriam relativamente raras, faz certo sentido que um administrador queira revisar e aprovar quaisquer alterações em vez de permitir uma atualização automática.
Para ser totalmente franco, se ninguém sabe por que essa configuração está habilitada em um determinado ambiente, isso significa que ela não deve ser definida.
Os computadores do domínio teriam permissão para verificar a lista de CAs confiáveis no Microsoft Windows Update Site e possivelmente adicionar novos certificados em seu armazenamento de certificados confiáveis.
Se isso for inaceitável para seus clientes/clientes, os certificados podem ser distribuídos pelo GPO e eles precisarão incluir seu certificado em qualquer método de distribuição que usem atualmente para certificados confiáveis.
Ou você sempre pode sugerir a desativação temporária dessa política específica para permitir a instalação do seu produto.
Meu motivo para desabilitar o certif.service é o seguinte:
Eu tenho muitos sistemas sem conexão com a internet. Além disso, na maioria dos casos, eles não possuem display/kb/mouse devido ao fato de serem máquinas virtuais em um grande DatastoreServer. Portanto, em todos os casos em que eles precisam de manutenção/modificação, eu uso o Windows RDP para acessá-los. Se você se conectar a uma máquina via RDP, o Windows primeiro verificará as atualizações de certificado online. Se o seu servidor/cliente não tiver internet, ele trava por 10 a 20 segundos antes de continuar a conexão.
Eu faço muitas conexões RDP todos os dias. Economizo horas sem olhar para a mensagem: "segurando a conexão remota":) +1 para desabilitar certif.service!
Eu não concordaria que é comum desabilitar isso. Uma maneira melhor de expressar isso seria perguntar por que alguém o desabilitaria. E uma solução melhor para o seu problema seria o instalador verificar os certificados CA raiz/intermediários e instalá-los se não estiverem presentes.
O programa Trusted Root CA é essencial. MUITOS aplicativos simplesmente não funcionariam como esperado se fossem desativados amplamente. Claro, pode haver algumas organizações que desabilitam esse recurso, mas isso depende realmente das organizações, com base em seus requisitos. É uma suposição falha de que qualquer aplicativo que exija uma dependência externa (certificado raiz) sempre funcionaria sem testá-lo. Tanto os desenvolvedores de aplicativos quanto as organizações que desabilitam esse recurso têm a responsabilidade de garantir que a dependência externa (certificado raiz) esteja presente. Isso significa que, se uma organização desabilitar isso, ela saberá que deve esperar esse problema (ou logo saberá sobre isso).
Também vale a pena notar que uma finalidade útil do mecanismo de programa CA raiz confiável (instalação dinâmica de certificados CA raiz) é que não é prático instalar todos ou mesmo a maioria dos certificados CA raiz conhecidos/confiáveis. Alguns componentes do Windows quebram se houver muitos certificados instalados, portanto, a única prática viável é instalar apenas os certificados necessários, quando necessários.
http://blogs.technet.com/b/windowsserver/archive/2013/01/12/fix-available-for-root-certificate-update-issue-on-windows-server.aspx
"O problema é o seguinte: o pacote de segurança SChannel usado para enviar certificados confiáveis aos clientes tem um limite de 16 KB. Portanto, ter muitos certificados no armazenamento pode impedir que os servidores TLS enviem as informações necessárias do certificado; eles começam a enviar, mas precisam parar quando eles atingem 16 KB. Se os clientes não tiverem as informações de certificado corretas, eles não poderão usar serviços que exigem TLS para autenticação. Como o pacote de atualização de certificado raiz disponível no KB 931125 adiciona manualmente um grande número de certificados ao armazenamento, aplicando-o aos resultados dos servidores na loja excedendo o limite de 16 KB e a possibilidade de falha na autenticação TLS."
Eu sei que este é um tópico antigo; no entanto, gostaria de apresentar uma solução alternativa. Use uma autoridade de certificação (ROOT CA) diferente da que você está usando. Em outras palavras, mude seu certificado de assinatura para um que tenha uma CA raiz aprovada muito mais antiga.
DIGICert oferece isso ao solicitar um certificado. Embora possa não ser sua CA raiz padrão em sua conta DIGICert, é uma opção disponível ao enviar o CSR para eles. BTW, eu não trabalho para o DIGICert nem tenho nenhum ganho em recomendá-los. menos tempo lidando com os problemas de suporte. Este é simplesmente um exemplo. Existem outros provedores de certificados que oferecem a mesma coisa.
Advertência - se você selecionar a CA raiz correta ao fazer o CSR.