0
votes

Certificat SSL pour Inlauche Kubettes

Je veux créer une entrée HTTPS pour mon infrastructure de microservice, sur Google Kubettes Engine, pour mon Strong> Environment Test Strong>. Une entrée HTTP de base fonctionne bien et je veux maintenant créer une sécurité sécurisée. Je n'ai pas de domaine, je veux que mon interface utilisateur effectue des demandes via https directement sur l'entrée IP d'entrée.

J'ai utilisé, retirons (SSLForFree Site Web) pour créer un certificat pour une adresse IP accessible à moi. Mais cette adresse IP que j'ai utilisée pour le nom de domaine dans le certificat n'est pas l'adresse IP sur laquelle l'entrée a été créée. Maintenant, toutes les demandes renvoient 401 et je ne sais pas pourquoi. Première erreur Le navigateur renvoie est le suivant: P>

Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for 35.241.60.223. The certificate is only valid for 35.228.159.214.
 
Error code: SEC_ERROR_UNKNOWN_ISSUER


3 Réponses :


2
votes

4 commentaires

Je reçois donc un domaine, créez un certificat pour ce domaine. Après cela, je crée l'entrée avec ce certificat, rediriger l'URL du domaine à l'URL d'INGRESS et cela devrait fonctionner?


Cela dépend de la manière dont vous créez vos certificats et vos entrées. Où obtenez-vous le certificat LETSENCRYPT? Utilisez-vous le CERT-Manager au sein de Kubettes? Ensuite, jetez un coup d'œil à l'autre réponse, l'entrée doit être configurée pour utiliser LETSENCRYPT. Mais pour que cela fonctionne, votre nom de domaine doit déjà indiquer la propriété intellectuelle. Sinon, cela dépend de l'ingression que vous utilisez et de la manière dont vous pouvez insérer votre certificat à votre entrée. Généralement via des secrets de Kubettes ou similaires.


J'ai fait ça et la demande Comanddev.tk/business-owner-Service/actuateur/Health < / a> retour sec_error_unknown_issuer


Cette réponse est uniquement sur Firefox, sur chrome, je reçois ERR_TIMED_OUT



1
votes

Cela se produit probablement en raison de la configuration de Clusterissuer / émetteur + Ingress que vous avez. Veuillez suivre les étapes suivantes pour avoir la bonne configuration:

   apiVersion: cert-manager.io/v1alpha2
   kind: Issuer
   metadata:
     name: letsencrypt-prod
   spec:
     acme:
       # The ACME server URL
       server: https://acme-v02.api.letsencrypt.org/directory
       # Email address used for ACME registration
       email: user@example.com
       # Name of a secret used to store the ACME account private key
       privateKeySecretRef:
         name: letsencrypt-prod
       # Enable the HTTP-01 challenge provider
       solvers:
       - http01:
           ingress:
             class: nginx
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kuard
  annotations:
    kubernetes.io/ingress.class: "nginx"    
    cert-manager.io/issuer: "letsencrypt-prod"

spec:
  tls:
  - hosts:
    - example.example.com (you probably have an DNS default)
    secretName: quickstart-example-tls
  rules:
  - host: example.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: kuard
          servicePort: 80


1 commentaires

J'utilise mes propres conteneurs (qui sont essentiellement des applications Springboot). Quelle ingress.class est-ce? Je ne pense pas que ce soit nginx