☰

verifique se existe um registro DNS para este domínio

tag-icon • tag-icon nginx cert-manager
verifique se existe um registro DNS para este domínio

Tenho o seguinte arquivo de manifesto de entrada:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  namespace: fsm
  name: fsm
  labels:
    app: fsm
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    cert-manager.io/issuer: "letsencrypt-staging"
spec:
    tls:
    - hosts: 
      - k8s-cluster.int
      secretName: quickstart-example-tls
    rules:    
    - host: k8s-cluster.int
      http:
        paths:
          - path: /fsm(/|$)(.*)
            backend:
              serviceName: fsm
              servicePort: 8081

Estou trabalhando com VMware com Vsphere. Eu não tenho um domínio comowww.google.com, apenas um nome DNS que é k8s-cluster e o domínio .int (dentro da minha empresa). Quando tento gerar o certificado recebo este erro: "msg"="error waiting for authorization" "error"="acme: authorization error for k8s-cluster.int: 400 urn:ietf:params:acme:error:dns: DNS problem: NXDOMAIN looking up A for k8s-cluster.int - check that a DNS record exists for this domain" "dnsName"="k8s-cluster.int" "resource_kind"="Challenge" "resource_name"="quickstart-example-tls-w7vj9-4141989927-3312743172" "resource_namespace"="fsm" "resource_version"="v1" "type"="HTTP-01"

Esse problema pode aparecer porque k8s-cluster.int está dentro de uma intranet? Se eu enrolar k8s-cluster.int

<html>
<head><title>308 Permanent Redirect</title></head>
<body>
<center><h1>308 Permanent Redirect</h1></center>
<hr><center>nginx/1.19.1</center>
</body>
</html>

Então, acho que o DNS funciona.

Responder1

Você tentou usar ACME, é o que Let's Encrypt usa. O protocolo ACME é basicamente uma validação automatizada de domínio DNS e fornece certificados de "domínio validado". Ele verifica se os registros DNS com nomes solicitados realmente apontam para o servidor solicitante (ou estão sob controle do servidor solicitante), o que "prova" que o servidor tem permissão para ter tal certificado.

Isso significa que a validação de domínio só é possível para nomes de domínio que estão na árvore DNS global. Você usa um sufixo ".int" que não existe na árvore DNS global (ou existe, mas seu nome não existe ou não pertence a você). Não é o que poderia ser "validado por domínio" com ACME.

Portanto, você não pode gerar certificados com ACME para este nome. Desculpe.

Suas opções são:

  • instancie sua própria CA "interna", tenha seus certificados raiz confiáveis ​​em todas as máquinas envolvidas e gere certificados com ela. Pode ser, por exemplo, Serviços de Certificação MS AD. Isso exigirá algum trabalho de instanciação e suporte da CA, mas você poderá continuar usando ".int";
  • use um subdomínio de domínio registrado globalmente, ou seja, altere seu sufixo ".int" para algo como ".int.example.com", onde exemplo.com é o seu domínio comprado e delegado. Então você pode, por exemplo, configurar algum proxy reverso e apontar todos os seus nomes "internos" para o endereço público desse proxy no DNS global, para poder usar o ACME para seus hosts "internos".

Depois de muitos anos de experiência em engenharia de rede, acabei com esta segunda alternativa. Eu nunca uso nomes "internos privados desanexados" como ".int", ".local", ".lan" etc. para serviços internos, mesmo sabendo que não vou conectá-los ao "mundo externo", mesmo que eles estão fisicamente desconectados da Internet. Eu sempre uso algo que descende dos nomes de domínio globais de minha propriedade. Isso me poupou muito trabalho. E quando às vezes encontro uma rede onde esses nomes "desconectados" são usados, quase sempre há algumas peculiaridades para resolver problemas obscuros, que não seriam necessários se estivessem usando nomes globais.

informação relacionada