HTTPS not working with Public IP/FQDN configured with Let's Encrypt wildcard certs

[alarmdev]

Describe the bug

here is my setup:

1. wildcard certificates are generated through letsencrypt (it works successfully with other projects so no issue with certs)
2. tried installing educates using both methods (straight educates create-cluster and on minikube)
3. configured config.yaml so that the workshop URL is getting generated with https using the TLS certificate configured in K8S
4. External DNS is already mapped with FQDN generated by Educates browse workshop with public IP of a VPS provider

The URL does not work, i.e. the workshops are not accessible.
The only installation works is using nip.io which is using the public IP configured on Ubuntu running on VPS and non-secure HTTP URL
Any suggestions on how to make it friendly URL with https, want to deploy multiple portals and workshops

Additional information

No response

[GrahamDumpleton]

In the namespace where the training-portal is deployed, eg., educates-cli-ui, is there a secret with name that looks like the TLS certificate, eg., educates-local-dev.test-tls?

This secret would be copied here by the secret-copier in Educates.

If you had originally created your TLS certificate as a secret and set up Educates config with reference to that secret, should have same name as your original.

If you had added the TLS certificate inline to the Educates config, the name of the secret should be the DNS name with -tls suffix. You should also find a copy of that secret in the educates namespace as that is where source copy is created when define it inline in the Educates config, and it is that from which a copy is made into the training portal namespace.

Two reasons why might not get copied to training portal namespace.

First is if use a reference to your TLS secret, the namespace/name isn't correct for where it is installed.

Second is that maybe hit an issue where there secret-copier stops working. I can't remember the original cause for that right now and we could well have fixed it, but if don't see secrets being copied around as required, delete the secret-copier-abcdeabcde-abcde pod in the educates namespace to trigger redeployment of the pod.

[alarmdev]

Hi,
Yes the secret was added in the config.yaml during cluster build out and was added to default namespace

educates-secrets -tls kubernetes.io/tls 2 2d18h

[GrahamDumpleton]

So in the namespace where the training-portal deployment is, is there a copy of that educates-secrets-tls secret?

[GrahamDumpleton]

If there is a copy of the secret, does it have tls.crt and tls.key data values? And if decode the values of those data values (base64 encoded), do you see the certificate and private key certificates as expect?

The tls.crt decoded value should start with -----BEGIN CERTIFICATE----- and the tls.key value should start with -----BEGIN PRIVATE KEY-----.

[jorgemoralespou]

I think this might be a routing or timing issue. I'm not very familiar with VPS, but from what I understand in your comment, you're assigning the public IP of a VPS server as the IP you have mapped to the DNS you assigned to the platform/installation/certificate.

• If you can access the service via this IP and nip.io, it means that the platform/workshop is properly deployed (although maybe not properly configured)
• If you can not access via the assigned DNS name that is mapped to that IP, then maybe it's a resolution problem. Have your tried verifying that the DNS properly resolves to the IP from your local system?
• If you can resolve the IP, but the https endpoint is not responding, then it might be a configuration issue with TLS and the wildcard certificate.

For this type of troubleshooting, it's always handy to paste the config you're using to bootstrap educates (anonymizing whatever necessary). This will help us understand what additional packages, if any, are installed, and how. You can use the following command: educates admin platform values --from-cluster

Also, for this type of troubleshooting, it's easier to do live chat on slack. I'm in EU timezone, so you might be able to reach me in your morning, and see if I can help.