You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Until now, I was only using the (great) internal CA of debops.pki. But today, on one machine, I need both the internal CA's cert (say example.com, from default realm domain), and a Let's Encrypt one (example.net, from this host realm). So in the inventory of this host, I added:
But when I run the PKI role on this host, this realm example.net's cert is created, but it's signed by our internal CA, not by Let's Encrypt! (and it's Subject Alternative Name includes the default domain realm wildcard, although the acme_subdomains does not include it)
openssl x509 -noout -text -in example.net/default.crt
...
Issuer: O = My Organisation, OU = Domain CA, CN = My Organisation Domain CA
Subject: CN = example.net
...
X509v3 Subject Alternative Name:
DNS:example.net, DNS:*.example.net
Moreover, if I run again the role, then the task Sign certificate requests for current hosts now always fails:
TASK [debops.debops.pki : Sign certificate requests for current hosts] ********************************
fatal: [myhost -> localhost]: FAILED! => [...], "stderr": "pki-authority: Error:
failed to run verify -CAfile issuer/subject/cert.pem -untrusted subject/cert.pem
/home/mathieu/ansible/secret/pki/realms/by-host/myhost/example.net/internal/cert.pem
(Exitcode: 2)\n\nDetails:\nCN = example.net
\nerror 47 at 0 depth lookup: permitted subtree violation
\nerror /home/mathieu/ansible/secret/pki/realms/by-host/myhost/example.net/internal/cert.pem:
verification failed", [...]
Which is actually expected, because this CA signs domains under example.com, not example.net. But why this task successed at the first run of the role?!
TASK [debops.debops.pki : Sign certificate requests for current hosts] ********************************
ok: [myhost -> localhost]
What am I missing?
The text was updated successfully, but these errors were encountered:
Even if I set only pki_default_realms for this host (which overwrite the default domain realm), it's certificate still get signed by our Debops CA! I really don't understand why. 🤔
pki_default_realms:
- name: 'foo.example.net'acme: True# This `www` is actually *not* added to SAN!# X509v3 Subject Alternative Name:# DNS:foo.example.netacme_subdomains: [ 'www' ]acme_ca: 'le-staging-v2'# Have to unset default_subdomains, otherwise `*.foo.example.net` is added to SAN.# X509v3 Subject Alternative Name:# DNS:foo.example.net, DNS:*.foo.example.netdefault_subdomains: []
openssl x509 -noout -text -in /etc/pki/realms/foo.example.net/default.crt
#...
Issuer: O = My Organisation, OU = Domain CA, CN = My Organisation Domain CA
Until now, I was only using the (great) internal CA of debops.pki. But today, on one machine, I need both the internal CA's cert (say
example.com
, from default realmdomain
), and a Let's Encrypt one (example.net
, from this host realm). So in the inventory of this host, I added:But when I run the PKI role on this host, this realm
example.net
's cert is created, but it's signed by our internal CA, not by Let's Encrypt! (and it's Subject Alternative Name includes the defaultdomain
realm wildcard, although theacme_subdomains
does not include it)openssl x509 -noout -text -in example.net/default.crt ... Issuer: O = My Organisation, OU = Domain CA, CN = My Organisation Domain CA Subject: CN = example.net ... X509v3 Subject Alternative Name: DNS:example.net, DNS:*.example.net
Moreover, if I run again the role, then the task
Sign certificate requests for current hosts
now always fails:Which is actually expected, because this CA signs domains under
example.com
, notexample.net
. But why this task successed at the first run of the role?!What am I missing?
The text was updated successfully, but these errors were encountered: