Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error every second pki run #125

Open
erikschwalbe opened this issue Mar 26, 2018 · 9 comments
Open

Error every second pki run #125

erikschwalbe opened this issue Mar 26, 2018 · 9 comments

Comments

@erikschwalbe
Copy link

erikschwalbe commented Mar 26, 2018

I think since yesterday after a debops-update the pki role failed with every second run:
TASK [debops.pki : Sign certificate requests for current hosts] **************************************************************************************************************************************
fatal: [teamcity -> localhost]: FAILED! => {"changed": false, "cmd": ["./lib/pki-authority", "sign-by-host", "teamcity.domain.com"], "delta": "0:00:00.305034", "end": "2018-03-26 09:41:34.501734", "msg": "non-zero return code", "rc": 2, "start": "2018-03-26 09:41:34.196700", "stderr": "pki-authority: Error: failed to run verify -CAfile issuer/subject/cert.pem -untrusted subject/cert.pem /home/ansible/debops/ansible/secret/pki/realms/by-host/teamcity.domain.com/domain/internal/cert.pem (Exitcode: 2)\n\nDetails:\n/home/ansible/debops/ansible/secret/pki/realms/by-host/teamcity.domain.com/domain/internal/cert.pem: CN = teamcity.domain.com\nerror 47 at 0 depth lookup:permitted subtree violation", "stderr_lines": ["pki-authority: Error: failed to run verify -CAfile issuer/subject/cert.pem -untrusted subject/cert.pem /home/ansible/debops/ansible/secret/pki/realms/by-host/teamcity.domain.com/domain/internal/cert.pem (Exitcode: 2)", "", "Details:", "/home/ansible/debops/ansible/secret/pki/realms/by-host/teamcity.domain.com/domain/internal/cert.pem: CN = teamcity.domain.com", "error 47 at 0 depth lookup:permitted subtree violation"], "stdout": "", "stdout_lines": []}

@drybjed
Copy link
Member

drybjed commented Mar 26, 2018

The "permitted subtree violation" error is related to use of nameConstraints extension. Basically, you tried to sign a certificate with a domain for which your CA is not allowed to sign certificates. Especially that the domain you tried to sign is .com...

I bet that you tried to create a host with FQDN similar to example.com. DebOps uses ansible_fqdn and ansible_domain variables in many roles, and with the FQDN like the above, the ansible_domain value would end up as .com, which cannot realistically work for a X.509 certificate. You should either change the hostname to something like host.example.com, in which case Ansible will detect the domain correctly, or enforce the values by setting pki_fqdn and pki_domain variables in the Ansible inventory.

@erikschwalbe
Copy link
Author

erikschwalbe commented Mar 26, 2018

sorry, there was a copy-paste failure.
I want to use a normal wildcard ssl certificate from comodo.

@drybjed
Copy link
Member

drybjed commented Mar 26, 2018

I see. Still, check what domains are recognized by your internal CA and what domains you tried to sign with it:

openssl x509 -in path/to/cert.pem -text -noout

@erikschwalbe
Copy link
Author

erikschwalbe commented Mar 26, 2018

openssl x509 -in ansible/secret/pki/realms/by-group/debops_service_pki/domain/external/all.domain.com.crt -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
18:cc:82:0a:b9:7a:52:60:45:60:e0:b5:88:93:05:f9
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA
Validity
Not Before: Mar 20 00:00:00 2018 GMT
Not After : May 19 23:59:59 2019 GMT
Subject: OU=Domain Control Validated, OU=EssentialSSL Wildcard, CN=*.domain.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)

Its a commercial wildcard certificate.

@drybjed
Copy link
Member

drybjed commented Mar 26, 2018

So it's an external certificate? That changes things a bit... In that case it would be best if you put these certificates in their own PKI realm, not domain. This new realm could have the internal CA disabled so that the debops.pki CA does not try to sign the certificate over and over. You can do this by adding in the inventory:

pki_realms:
  - name: 'domain.com'
    internal: False
    acme: False

Then you can point services like nginx at this new PKI realm to use the external certificate.

@erikschwalbe
Copy link
Author

Ok, sorry for that missing information.
debops created the new realm.
Is it possible to disable the domain realm? so, that there is only the commercial certificate.

@drybjed
Copy link
Member

drybjed commented Mar 26, 2018

Sure, you could set pki_default_realms: [], and pki_system_realm: 'new.realm.name'. Although I'd keep the domain` realm for inter-cluster communication if you have more hosts.

@erikschwalbe
Copy link
Author

Sorry, but another question. If debops created the folder structure ansible/secret/pki/realms/by-group/debops_service_pki/example.com whats the prefered way to include the commercial certificate or where is the right place to copy?
At the moment there are 2 folders: external and private
But on the destination host the default.crt does not point to my certificate.

@drybjed
Copy link
Member

drybjed commented Mar 26, 2018

The PKI realm is designed around a single private key, but if you are using external cert/key pair the key generated by the realm will be invalid (debops.pki does not update the realm key automatically). Remove the PKI realm to reset it.

Put your private key, in the private/ directory of the generated directory structure. Put your certificate, intermediate and root .pem files in the external/ directory. When you run debops.pki again, the role should copy the external CA files and use them automatically.

Read the external CA documentation for more details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants