StanTastic's questions

Suponha que eu tenha um CSR no qual alguns campos Assunto não foram criados de acordo com X.509 - existem caracteres proibidos em Assunto ou País foi fornecido como "Inglaterra".

Existe alguma maneira de se recuperar disso?

Eu tentei:

• usando policy.inf para renunciar ao certificado, mas não consigo encontrar nenhuma maneira de alterar o assunto existente
• editar solicitação diretamente na CA, mas como há algumas coisas proibidas no CSR, a solicitação falha imediatamente e o uso de certutil -setattributes resulta em "CERTSRV_E_BAD_REQUESTSUBJECT" (meio esperado, mas um pouco estranho, pois você pode tentar reemitir uma solicitação que está em lista "Falha").

Eu não acho que "consertar" um CSR ruim é possível aqui, mas talvez eu esteja errado?

Desejo verificar a operação do servidor Microsoft OCSP no Linux. Eu tentei usar o OpenSSL, mas ele sempre retorna:

Error querying OCSP responder 140643157128320:error:27076072:OCSP routines:parse_http_line1:server response error:../crypto/ocsp/ocsp_ht.c:260:Code=405,Reason=Method Not Allowed

Verifiquei no lado do servidor e notei que o OpenSSL usa o método POST, em oposição ao método GET usado pelo certutil (que funciona bem):

# certutil Request
2021-09-28 10:26:51 10.11.12.13 GET /ocsp/<OCSP request> - 80 - 10.11.12.14 Microsoft-CryptoAPI/10.0 - 200 0 0 4583
# OpenSSL Request
2021-09-28 10:26:51 10.11.12.13 POST / - 80 - 10.11.12.15 - - 405 0 1 5991

Parece que o OpenSSL não pode ser forçado a usar GET em vez de post, mas talvez haja algum outro utilitário?

Ou, inversamente, existe um método para forçar o respondedor do MS OCSP a trabalhar com o POST também?

Preciso atualizar um dos meus modelos de certificado dos Serviços de Certificados do Active Directory (ADCS) do esquema v2 para v3, para oferecer suporte a provedores KSP. Parece que só posso fazer isso clonando o modelo (só então recebo a opção de selecionar KSP).

É possível fazê-lo in loco? Se sim, como?

O negócio é o seguinte: a política da empresa é atualizar as senhas das contas de serviço a cada 180 dias. O problema é que estou usando essas contas de serviço em cerca de 20 servidores, executando vários trabalhos - então, a cada 180 dias, tenho que gastar 4 horas atualizando todos eles (se não fosse o autotype do KeepassXC, levaria mais de 2 dias, tenho que adoro RDP para DC meio mundo de distância).

Tem que haver uma maneira melhor, mas qual seria?

Estamos falando de W2k12r2.

No meu ambiente AD, implantei um modelo que fornece certificados RDP para servidores. Está definido na inscrição automática.

O problema é que a maioria dos servidores funciona como eu esperava: eles conseguiram o certificado e é o suficiente para eles. No entanto, poucos servidores obtêm um novo certificado a cada 12 horas. Eu li o artigo https://social.technet.microsoft.com/wiki/contents/articles/38085.certificate-autoenrollment.aspx e entendo o que está acontecendo, mas não entendo POR QUE isso está acontecendo - o que aciona o servidor para solicitar um novo certificado, mesmo que já exista?

Não quero publicar os certificados no AD, especialmente porque apenas alguns servidores estão mostrando essa anomalia - outros estão bem. Todos os certificados gerados dessa forma ainda são válidos e a chave privada existe.

Não tenho certeza se é mesmo possível. Além disso, o OpenSSL é um amante feio de um utilitário :/

Preciso do certificado de upload superior + chave privada como DER para o ESET Security Management Center (ESMC), pelo menos de acordo com o suporte técnico.

Eu uso o XCA para esta pequena implantação e não há opção de exportar público + privado como DER, apenas PEM (ou alguns outros formatos). Então a questão é: como converter PEM privado+público para DER?

É 'legal' e possível no DNS encadear registros NS como este:

com. NS:

example.com NS ns1.example.com.
ns1.example.com A a.b.c.d

example.com. NS:

example.com NS azuredns.com.
azuredns.com. A x.y.v.z

A razão pela qual estou tentando tal configuração é que um de nossos departamentos não técnicos quer que tenhamos todos os domínios configurados em nosso sistema DNS; mas alguns deles utilizam recursos de provedores de DNS "nuvem". Não estou ansioso para fazer tais abominações, mas devo a devida diligência à minha empresa :-)

Antes que alguém pergunte: eu vi Quando as consultas DNS usam TCP em vez de UDP? e não responde a minha pergunta.

Tudo o que ouço é " se a resposta for muito longa, o DNS usará o TCP ". Isso não explica como isso acontece.

Então, aqui está a situação: o cliente DNS solicita a resolução de um registro usando UDP. O registro é muito longo para UDP:

1. respostas do servidor com opcode específico, para que o cliente mude para TCP
2. o servidor não responde e o cliente tenta novamente pelo TCP
3. servidor abre conexão TCP com cliente (estúpido, se você contar NAT, mas quem sabe?)
4. o cliente de alguma forma (?) 'sabe' que determinada consulta deve ser executada sobre TCP, para que não se incomode com o UDP em primeiro lugar
5. DNS pixies transformam magicamente UDP em TCP quando necessário

Procurei a resposta em toda a Internet, mas há muito ruído (veja acima) e não consigo escrever uma consulta adequada do Google para isso (nem consigo encontrar as informações em RFCs, nesse caso) .