shole's questions

Tenho uma VM RHEL9 registrada e recentemente clonei uma cópia dela restaurando a partir do backup mais recente do Veeam.

Depois alterei o IP, o gateway, também /etc/hostso arquivo e regenerei /etc/machine-ido arquivo (também /var/lib/dbus/machine-id)

Então eu executei subscription-manager unregistere subscription-manager cleanem ambas as VMs. Também fiz login no console web do Redhat Hybrid Cloud Console para verificar se não há sistemas relevantes registrados.

Então eu executei subscrption-manager registerpara ambas as VMs, e esperava que houvesse duas novas entradas no Redhat Hybrid Cloud Console. No entanto, descobri que sempre há apenas uma entrada, e parece que as VMs estavam sobrescrevendo uma à outra.

Verifiquei se eles têm dois IPs, IDs de máquina e identidade de gerenciador de assinaturas diferentes, mas parece que quando tento registrar os dois, o Redhat os vê como o mesmo sistema.

Minha pergunta é: qual é a possível causa desse comportamento e como posso resolvê-lo corretamente?

2025-01-06 Atualização rápida:

Seguindo a resposta sugerida, tento atualizar o MAC Address, mas o Redhat parece ainda não conseguir dizer que são duas VMs diferentes. Abaixo está minha configuração atual da VM original e da VM restaurada.

• VM original:

Endereço IP e MAC

/etc/machine-id e /var/lib/dbus/machine-id

identidade do gerenciador de assinaturas

• VM restaurada:

Endereço IP e MAC

/etc/machine-id e /var/lib/dbus/machine-id

identidade do gerenciador de assinaturas

Sou muito novo no mundo de servidores e redes, espero que as perguntas sejam claras e não sejam tão triviais. Recentemente me deparei com o seguinte cenário:

1. Havia um certificado Root A, que vai expirar alguns meses depois. Havia outro novo certificado raiz B, que pretendia substituir o A. Ambos, A e B, são autoassinados. O CA de A é confiável por navegadores / sistemas operacionais novos e antigos, enquanto o CA de B é confiável apenas por navegadores / sistemas operacionais modernos

2. Havia um certificado cruzado A->B (B assinado por A) que está sendo usado atualmente em nossos servidores. No entanto, como A vai expirar em breve, aplicamos outro certificado cruzado C->B (B assinado por C, cuja CA de C é confiável para navegadores/SO antigos e novos) como substituto.

3. Agora, no ambiente UAT, atualizamos o certificado C->B e, para o lado do cliente, tento usar alguns navegadores legados para teste, verifiquei que apenas o CA de A e o CA de C são confiáveis, enquanto o CA de B não é. Para o ambiente PROD, permanecemos inalterados, ou seja, usando o certificado A->B

4. Eu acesso o site UAT com o navegador mencionado, e verifiquei que o certificado usado é A->B, pela primeira vez. Surpreendentemente, para acesso posterior aos sites UAT e PROD, o certificado usado é C->B (verificado no lado do cliente).

Minha pergunta é, esse comportamento é normal? Por que o lado do cliente "sabe" usar C->B desde o primeiro acesso aos sites UAT? Eu também uso openssl s_clientpara verificar se o servidor PROD ainda está usando A->B. Como os navegadores sabem qual certificado usar e "atualizam" o certificado de acordo?

Editado em 2022-dez-13

1. Nosso principal objetivo é oferecer suporte a navegadores / sistemas operacionais muito antigos e navegadores / sistemas operacionais modernos. ou seja, todos os navegadores podem acessar nosso site com sucesso, mesmo após a expiração do certificado A.
2. Acho que minha principal pergunta, ou dúvida, é se o seguinte é verdade:

• Navegadores antigos, pela primeira vez acessando o site UAT, mostra que o servidor está usando cert A->B devido a algum mecanismo de cache
• Após o primeiro acesso ao site UAT, o servidor realmente "empurra" o novo certificado C->B para o lado do cliente que está configurado no servidor. Agora, os navegadores ou até mesmo o nível do sistema operacional reconheceram que o certificado mais recente é C->B, não mais A->B.
• Embora C->B seja reconhecido, o certificado A->B ainda é salvo no navegador/SO. Mas o navegador de alguma forma sabe verificar com o certificado C->B mais recente. Ou seja, nosso propósito pode ser alcançado.