I am working on adding a TLS certificate to the Incus daemon on my laptop. Actually I am just setting up a WebUI to manage it. Here are my key settings:
Host: Debian 13 x64
Incus package: 6.12-debian13-202505151659 from Zabbly
Host user: a normal desktop user without membership of incus-admin group.
Incus project: user-1000 set up by Incus automatically.
I look through to the guides in the documents, blogs and posts[1][2], but I got a little confused when I tried them on.
First, I followed the instructions to add the TLS certificate, but I got the error “not authorized”, I also got another “Certificate is restricted” error when I tried to set up the Incus daemon to expose the WebAPI as follows.
$ nano mywebui.crt # Save certificate
$ incus config trust add-certificate mywebui.crt
Error: not authorized
$ incus config set core.https_address="[::]:8443"
Error: Certificate is restricted
These errors can be mitigated simply by running them as sudo, and the Web UI then run smoothly.
Is such behavior in line with expectations or related to my settings? The docs I referred to did not mention the need to be “sudo” or “incus-admin” to do so. Or am I missing something?
Does the certificates added to trust pool have accesses to all projects or users’ resources? I found that I can switch between projects in WebUI with this certificate.
To be honest, I am a little confused about the role of the certificate. Is this certificate used for the TLS traffic encryption between client and server ONLY? Or does it also indicate the identity of the user?
Further, is it possible to make the certificate as a “user-space” resource? That is, the certificate can be added as a normal user without “sudo” or “incus-admin”, and the certificate grants only accesses to the user’s resources.
I’m not very familiar with this area, and thank you for your patience in responding.
The Error: not authorized error might be related to the general Incus configuration. Youir non-root account probably does not belong to the incus-admin Unix group, but rather to the incus group which is somewhat restricted.
To verify, run
$ groups
.... incus-admin ...
Also, when you run incus info and you are a restricted user, you would get
project: myusername-00x, and not default.
auth_user_method: tls, and not unix (using the Unix group membership).
Therefore, my running sudo in front of the incus command, you have been bypassing the restricted user setup.
Hence, if that’s the case, add your non-root account to the incus-admin group.
Thank you for your reply and your detailed, lovely blogs for Incus!
Adding a UNIX user to incus-admin group works perfectly, and it is the ideal solution for daily desktop use.
It might be a bit off-topic, but I am still curious about how Incus deals with the certificate and connection authentication.
My concern is that, by adding the certificate to the trust pool, the client seems to have the same privileges as incus-admin, which might not be what expected especially in a network.
I used to think that certificates were tied to a user’s identity and that accessing the Incus daemon with a key corresponding to a certificate indicated the user’s identity, just like the common SSH setup.
However, it seems that I was mistaken about this in Incus.
So is it possible to allow a client connection (like WebUI) with a trusted certificate, while limiting the connection’s privileges and accesses, e.g. project-specific, just like the non-incus-admin users do in their shell?
