[debops-users] usage of pki service - how to create new root ca
drybjed at drybjed.net
Fri Nov 24 00:18:22 CET 2017
On Nov 23, Jan Kowalsky wrote:
> Hi all,
Hello, welcome to the project.
> I wondering how to use the pki service with debops. I read documentation
> but actually it didn't answer all my questions ;-).
> What I reallized: When setting up the first host with pki_enabled: True
> (default) debops is generating a root certificate and a first
> certificate for this host. Well. Since I want't to test if the pki
> service is the right thing for us (at the moment we use an self scripted
> internal completely offline CA) - of course the first root certificate
> is not the one we will continue with.
> So I tried to delete the pki directory on the ansible controller - and
> thought the root certificate is generated again. But this is not the fact.
> How is it possible to initialize a completely new certificate auhtority
> while there are already hosts in the same ansible domain?
The 'debops.pki' role depends on few things like presence of the generated
private keys and certificates to no overwrite the certs over and over. If you
want to reset it, removing the 'secret/pki/' directory (entire) on the Ansible
Controller, as well as the '/etc/pki/realms/' directories on the remote hosts
should be sufficient to create a new set of CA and certificates.
Keep in mind that if you recreate the Root CA certificate, you need to re-sign
all of the remote host certificates anyway. And no, at the moment the role
doesn't recognize that the Root CA has changed, so you still need to remove
the PKI realm directories to initiate the re-signing.
> Is there any way to use already existent key pairs for root ca?
You can carefully replace the already existing Root CA and intermediate CA
certificates and keys with your custom ones, and the 'debops.pki' should
continue as normal, signing host certificates with the new CA. You don't need
to keep the Root CA private key inside the 'secret/pki/' directory, that's why
an intermediate CA exists.
> And still there is the problem that encfs on debian stretch isn't
> working (but this is another story).
EncFS in itself is considered as insecure:
I chose it as the DebOps encryption method because it didn't require root
access to lock/unlock the encrypted directories, and was portable enough that
the encrypted data could be kept in the git repository, the same as the rest
or a separate. If you plan to use it, I would suggest to use an encrypted
filesystem underneath as well, for example LUKS, to ensure better security.
Of course EncFS is completely optional and could be replaced by something
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 585 bytes
Desc: not available
More information about the debops-users