juju bootstrap to a maas-cloud with custom ca cert fails with tls error

getting started
,
1

Over the past few days I have been trying to bootstrap my juju controller - I am using maas 3.6 and know that my issues surround the fact that it has custom ca cert. The bootstrap proceeds to a certain point then i see the tls error

ERROR creating MAAS environ: Get “X.X.X.X:5443/MAAS/api/2.0/version/”: tls: failed to verify certificate: x509: certificate signed by unknown authority 2025-09-20 16:43:28 DEBUG cmd supercommand.go:571 error stack: Get “X.X.X.X:5443/MAAS/api/2.0/version/”: tls: failed to verify certificate: x509: certificate signed by unknown authority github.com/juju/gomaasapi/v2.(*controller)._getRaw:887: github.com/juju/gomaasapi/v2.(*controller)._get:863:

Ive gone down several rabbit holes from trying to use preceeds to install the ca cert in trusted store using preceed scripts and curtin scripts - I tried deploying a machine and adding the cert manually - but no matter what I end up with the tls error.

Can anyone advise - granted I am new to Maas so could very likely be missing something simple but just cant see it.

My Maas is also acting as my juju client Both maas and juju are installed using snap

maas 3.6.1-17573-g.bc3a12219 40143 3.6/stable canonical✓ -

juju 3.6.9 32163 3/stable canonical✓ -

So bottom line - need details of how to bootstrap juju with a maas custom ca cert.

Details of the single machine with the maas and juju snap Distributor ID: Ubuntu 24.04.3 LTS Release: 24.04 Codename: noble

Thanks for any help or guidance.

2

My latest attempt with this is using curtin/preceed scripts - I am creating a folder on the maas machine /var/snap/maas/current/preseeds/curtin/scripts Dropping my script in here that should copy the cert from /var/snap/maas/current/preseeds/curtin/my-ca.crt to /usr/local/share/ca-certificates/custom/my-ca.crt Changes permissions to 644 and then runs update-ca-certificates But the script never seems to run - Anyone had to do anything similar with curtin/preceed scripts - the documentation seems to vary but I think i have the right instructions for a snap install

3

After abandoning the preceed/curtin approach I came across this

Show and Tell: New MAAS TLS feature - Development - Canonical MAAS | Discourse

I created my cloud-init.yml to conform to the described in the procedure -

The command I then use is juju bootstrap maas-cloud mycontroller --config=cloud-init.yaml

I still see tls error at the end

No VM guests are running outdated hypervisor (qemu) binaries on this host. Fetching Juju agent version 3.6.9 for amd64 Attempt 1 to download agent binaries from ‘streams.canonical.com/juju/tools/agent/3.6.9/juju-3.6.9-linux-amd64.tgz’…\n Agent binaries downloaded successfully. d62f9dd53f10acc756ea898a8ab29c114d054b6e7c2dc18129873faaf2d615c9 /var/lib/juju/tools/3.6.9-ubuntu-amd64/tools.tar.gz Installing Juju machine agent 2025-09-21 12:05:55 INFO juju.cmd supercommand.go:56 running jujud [3.6.9 8ca5a5ce6d5be058aa99f340ac2d0592c4313d42 gc go1.24.6] ERROR creating MAAS environ: Get “X.X.X.X:5443/MAAS/api/2.0/version/”: tls: failed to verify certificate: x509: certificate signed by unknown authority ERROR failed to bootstrap model: subprocess encountered error code 1

–

I have done a test where i deploy a machine - do the curl to the url X.X.X.X:5443/MAAS/api/2.0/version/ then install the cert and do the curl again - so i know its the trusting of the ca root cert - I just dont seem to be able to find a way to pretrust it

-Pre manual install of ca

ubuntu@ready-gecko:/usr/local/share/ca-certificates$ curl X.X.X.X:5443/MAAS/api/2.0/version/ curl: (60) SSL certificate problem: self-signed certificate in certificate chain

curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above.

  • Post Manual Install of CA

ubuntu@ready-gecko:/usr/local/share/ca-certificates$ sudo update-ca-certificates Updating certificates in /etc/ssl/certs… rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d… done. ubuntu@ready-gecko:/usr/local/share/ca-certificates$ curl X.X.X.X:5443/MAAS/api/2.0/version/ {“capabilities”: [“networks-management”, “static-ipaddresses”, “ipv6-deployment-ubuntu”, “devices-management”, “storage-deployment-ubuntu”, “network-deployment-ubuntu”, “bridging-interface-ubuntu”, “bridging-automatic-ubuntu”, “authenticate-api”], “version”: “3.6.1”, “subversion”: “”}ubuntu@ready-gecko:/usr/local/share/ca-certificates$

How do I properly let juju know to expect an internal ca and pre trust it ?? I have tried several different routes but all have ended up with the same tls error

4

hi, I resolved adding –config “ssl-hostname-verification=false”
to juju bootstrap and it worked but from now every juju command fails with the same error

5

Hi @macchese & @william-conway,

Apologies for a late reply here. You can add your MAAS cloud to the juju client or controller by using juju add-cloud my-maas.yaml. Where my-maas.yaml is a definition of the cloud and can include the trusted CA certificates. Our docs for this are here. An example might look like:

clouds:
  maas-trusted:
    type: maas
    auth-types: ...
    endpoint: https://maas.example.com/MAAS
    ca-certificates: |
      -----BEGIN CERTIFICATE-----
      MIID...
      -----END CERTIFICATE-----

If you look at ~/.local/share/juju/clouds.yaml you can find out what your current definition is and ad the ca-cert part.

6

I was able to add the cloud without issue and bootstrap the cluster without issue with a custom TLS cert - the issue was that any pxe boot after the tls cert change would give a TLS error. There were various recommendations to work around including baking the cert into a custom image. I would think once you’re tls cert is changed that Maas/JuJu should trust the updated cert in relation to deploy and pxe boot. For me as I am only testing it, the easiest way was to not enable Https with an internal ca cert. If I was to use in production I would expect enabling TLS with a custom TLS cert would automatically trust that cert for pxe deploys whether through JuJu or Maas Deploy.