Certificate validation error: "identity is not valid for provided host" despite host being listed as valid

Ziti Overlay
1

I'm encountering a persistent certificate validation error when setting up OpenZiti controller on TrueNAS. The error message appears contradictory and I've tried multiple approaches without success.

Error Message:

provided value for ctrl/options/advertiseAddress is invalid (identity is not valid for provided host: [192.168.100.6]. is valid for: [127.0.0.1, 192.168.100.6, ::1, localhost])

Environment:

  • TrueNAS Community Edition

  • OpenZiti v1.6.7

  • IP address: 192.168.100.6

What I've tried:

  1. Manual certificate generation using ziti pki create commands

  2. Official Docker containers with automatic certificate generation

  3. Using localhost/127.0.0.1 instead of IP address

  4. Both manual configuration and docker-compose approaches

The Issue: The error states that 192.168.100.6 is "not valid" but then lists it as one of the valid hosts. This seems contradictory. Both manual and automatic certificate generation produce the same error.

Question: Is this a known issue with certificate validation logic? The fact that the IP is listed as both invalid and valid suggests there might be a bug in the validation process.

Any guidance would be appreciated!

2

Hi @cstrong84, welcome to the community and to OpenZiti!

That sure does seem contradictory. " Question: Is this a known issue with certificate validation logic?". No, not that I know of but it sure does seem like a problem with validation.

Just guessing here, but can you list the cert's SANS? I am thinking the SANS has a "DNS" entry of 192.168.100.6 when it needs to be an ip entry. I'm thinking that it's a DNS entry not IP. That make sense?

3

I did not expect a reply this quickly. I have already deleted the docker container. I will regenerate it and get you that information.

Here is the cert data:
root@truenas[/mnt/Data/openziti]# openssl x509 -in ziti-ca/certs/server.cert -text -noout | sed -n '/Subject Alternative Name/,/[1]*$/p'

        X509v3 Subject Alternative Name: 
            DNS:localhost, IP Address:127.0.0.1, IP Address:192.168.100.6
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
    67:33:8d:f6:d6:94:d6:2a:01:a4:4f:5d:9a:be:b1:ab:06:fd:
    2c:5e:ad:7e:12:28:8d:3e:00:73:80:a1:00:cf:41:cd:aa:fc:
    c1:e9:94:4e:9e:e6:a8:25:66:d2:a3:50:fb:35:f5:1b:c4:2f:
    dc:06:85:4c:be:53:41:03:02:04:9e:cb:59:a0:e5:55:67:2b:
    2e:56:e2:8d:7d:b7:f9:5b:36:db:ca:8b:22:92:a3:4f:c5:da:
    63:a1:fe:24:c9:23:87:5b:e8:19:2e:19:92:05:8a:3b:74:9d:
    88:b4:b5:69:82:50:39:c0:32:c4:71:55:fa:a5:5d:cf:3d:da:
    39:b4:f2:f4:ac:31:c0:14:79:4e:58:e3:a7:f5:ce:67:8e:c1:
    19:de:68:2a:83:6c:1b:c0:a3:6a:12:30:23:a4:c1:cf:3f:be:
    fa:f8:3d:f8:e6:3d:0f:51:65:56:e4:11:df:eb:c1:51:62:bb:
    3c:9e:3b:36:ef:31:01:54:d9:e7:8d:3b:e2:62:62:a0:b2:52:
    4e:df:2f:f5:75:ea:19:ad:da:c8:0f:d2:37:55:ba:54:98:72:
    15:21:b3:ad:69:00:58:ed:25:3f:a3:ed:6e:d3:6f:53:f1:a1:
    83:0c:da:39:76:d3:1a:96:e1:27:b6:bf:bf:8e:a2:4d:51:84:
    28:0a:2d:55:78:a0:8a:7d:6c:69:fa:60:ec:b8:bb:04:e2:b2:
    6a:d3:51:ca:0c:5f:0a:7b:7f:fc:04:37:01:5e:81:0f:0d:a0:
    7c:98:27:b3:67:21:8e:8b:56:cc:85:e6:76:54:a1:f9:43:85:
    c0:5e:16:5b:46:d9:1b:06:fa:34:a0:49:7a:e4:95:7d:d9:5d:
    ca:95:33:ae:6f:aa:ac:3e:43:c4:bf:19:ad:46:a2:d1:b5:8d:
    f5:be:67:80:36:a9:48:c1:a0:25:3f:ae:ee:7e:6a:8a:9d:fa:
    c8:15:71:36:a2:67:bd:73:53:0b:ec:1e:9c:ca:6b:39:7e:04:
    2c:3c:57:28:dc:a4:1a:5b:8b:85:fc:c0:70:4a:60:18:b5:72:
    0b:12:1a:eb:ad:22:ba:6b:f1:1d:a1:92:fd:7c:f9:a8:f0:e7:
    3e:5b:9d:18:dd:b7:3f:2b:2a:1a:c9:93:26:6f:a6:b3:71:da:
    98:bb:1f:48:12:fe:e6:b5:6c:81:0a:04:6e:b5:d0:56:b6:cd:
    1a:42:5d:f3:ee:3a:c5:30:43:92:32:52:5b:ac:5e:55:3d:fd:
    e5:99:ec:7d:f3:1d:ee:c3:5e:4d:d1:61:e8:f7:c4:9b:3c:df:
    fd:03:11:aa:26:c6:10:4c:d4:f1:b7:48:2a:d4:a1:dc:5f:b3:
    49:b8:82:b3:e8:c9:c7:9c

root@truenas[/mnt/Data/openziti]#

  1. [:space:] ↩︎

4

Well then there's something to investigate here. Any chance you can reproduce and give me the steps? I'll have a look.

5

Okay, so I used the quick start guide and it seems to be working. I can use either 127.0.0.1 or the IP for my external network. So that progress.

6

How did you install the overlay to produce the issue, is what I'm asking. I would like to try to follow whatever steps you did.

7

I’ve encountered the same issue. I am trying to set up an OpenZiti environment in a local network. I’m currently trying to simply host the OpenZiti controller using Docker. Here is my configuration (docker-compose.yml):

services:
  ziti-controller:
    image: openziti/ziti-controller:1.5.10
    environment:
      - ZITI_CTRL_ADVERTISED_ADDRESS=10.10.0.44
      - ZITI_USER=admin
      - ZITI_PWD=admin
      - ZITI_CTRL_ADVERTISED_PORT=1280
    ports:
      - 1280:1280

When running docker compose up, I encounter the same error as previously mentioned. The full logs are the following:

ziti-controller-1  | Success
ziti-controller-1  | Using CA name:  root
ziti-controller-1  | Success
ziti-controller-1  | Using CA name:  intermediate
ziti-controller-1  | Success
ziti-controller-1  | {"file":"github.com/openziti/ziti/controller/config/config.go:405","func":"github.com/openziti/ziti/controller/config.LoadConfig","level":"warning","msg":"this environment is using a default generated trust domain [spiffe://27ae6aae3e91bcb6a69c0e4b78ade8dcaf6c431a], it is recommended that a trust domain is specified in configuration via URI SANs or the 'trustDomain' field","time":"2026-01-16T14:02:39.750Z"}
ziti-controller-1  | {"file":"github.com/openziti/ziti/controller/config/config.go:406","func":"github.com/openziti/ziti/controller/config.LoadConfig","level":"warning","msg":"this environment is using a default generated trust domain [spiffe://27ae6aae3e91bcb6a69c0e4b78ade8dcaf6c431a], it is recommended that if network components have enrolled that the generated trust domain be added to the configuration field 'additionalTrustDomains' array when configuring a explicit trust domain","time":"2026-01-16T14:02:39.750Z"}
ziti-controller-1  | {"file":"github.com/openziti/ziti/controller/config/config.go:588","func":"github.com/openziti/ziti/controller/config.LoadConfig","level":"fatal","msg":"provided value for ctrl/options/advertiseAddress is invalid (identity is not valid for provided host: [10.10.0.44]. is valid for: [10.10.0.44, 127.0.0.1, ::1, localhost])","time":"2026-01-16T14:02:39.750Z"}
ziti-controller-1  | ERROR: failed to create default admin in database
ziti-controller-1  | WARN: set VERBOSE=1 or DEBUG=1 for more output
ziti-controller-1  | WARN: see output in '/tmp/tmp.a4hS16PmEf'
ziti-controller-1 exited with code 1

Any help is welcome @TheLumberjack !

8

The issue only arises with "pure" IP addresses. Inputting characters that suggest the address is actually not a valid address "resolves" the issue (the controller start normally). For example, quick trial-and-error tests reveal that:

  • 10.10.0.44/22 starts normally;
  • 10.10.().44 starts normally;
  • 10.10.$.44 starts normally.

But this obviously does not work when trying to enroll through the controller located at 10.10.0.44. I think generally the input validation on ZITI_CTRL_ADVERTISED_ADDRESS needs to be looked at, as all of the mentioned strings are neither valid IP addresses nor valid domain names. I can try to look into it, if pointed in the right direction in the codebase!

For now, I've resorted to using dnsmasq in order to have custom domain names that resolve to my private IP addresses.

9

Hi @hosava3486, welcome to the community and to OpenZiti!

Have a look at this whole thread from last month and give it a try. Authentication Error (UNAUTHORIZED) when enrolling Identity (QuickStart Docker Compose) - #2 by TheLumberjack

I'm not exactly following what your problem is either. See if that other thread helps?