Renew puppet CA with puppetlabs/certregen - certificate

I'm trying to renew a Puppet CA certificate and propagate it to the agents according to this https://github.com/puppetlabs/puppetlabs-certregen manual. While the first step of regenerating the CA certificate was easy to do, distributing the new CA to the clients does not work.
I created a file in the /manifests folder of the puppet repository called ca.pp with the content include certregen::client, but after a puppet update on the server and puppet agent -t -v on one of the clients nothing changes. I still get the warning Warning: Certificate 'Puppet CA: puppetmaster.domain.name' will expire on 2019-10-20T10:35:43UTC.
Unfortunately I don't have much knowledge about puppet since I inherited the setup from a former colleague who isn't available any more. So I don't even know where to start to debug this issue. Any help is very much appreciated.

The file named ca.pp containing the line include certregen::client has to be imported in the sites.pp file with import 'ca.pp' in the main manifests directory.
After that step, the CA certificate was successfully distributed among the clients.

Related

Create EJBCA subCA during EJBCA installation

I am learning how to install and use EJBCA to deploy an enterprise PKI. I know I can install EJBCA using a quick install configuring the script ejbca-setup like is explained here, and I also have tested a longer install process with WildFly 10 like explained here. In both variants I need to create a default ManagementCA and I can make some configuration changes related to the database I'm using and other things during the installation process. My problem is I need to install a CA of subCA type, and my subCA private key comes in a PKCS12 or PEM file from the root CA (I'm not completelly sure about the format yet).
Right now I know I can install EJBCA with the default CA and then create my subCA as a second one like is explained here, but I want to know if I can create this subCA as my first CA at the installation process, because I dont't need the default CA. Also if I have to create the default CA mandatorily I want to know if I can remove this default CA after I create my subCA without problems or if this first default CA is some kind of special CA for EJBCA.
The default ManagementCA is nothing special and can be deleted.
You can make the initial installation using an external CA for administrator certificates if you like. Documented here: https://doc.primekey.com/ejbca/ejbca-installation/installing-ejbca/install-ejbca-as-a-ca-without-a-management-ca
Note the "-superadmincn" argument which binds your externally issued certificate to the suprt administrator role during the installation.

Openshift 4.2 - Unable to connect to the server: x509: certificate has expired or is not yet valid

I tried to create a cluster in Openshift 4.2 (RHCOS) environment. I have own local DNS server and HA proxy server. I created 3 master and 2 worker nodes in VMware Environment as per the documentation. At the end of the new cluster creation I'm getting an error :
Unable to connect to the server: x509: certificate has expired or is
not yet valid
Does anyone have an idea why am I getting this error?
It's an ignition file problem.When we create a ignition file, we have to finish the installation with in 24 hours.Because the ignition files contains certificate and it will expires in 24 hours.
You must delete all install folder. Not enough to delete inside of install folder. Because install folder contains hidden file and those files creates old ignition files.
Same problem.
But just regenerating ignition config files did not fix the problem.
To fix it I had to alto delete the auth/ subfolder & regenerate.

Same p12 certificate, different trust chain on different machines, why?

I have a p12 file. This was generated from a DigiCert p7b.
When I import this into my personal store on one machine (windows server, using certificates mmc) it shows me one chain when I view the path.
Using the same file, I import into my personal store on a different machine (also windows, using certs mmc). On this one I see a different path (and in this case it has an expired hop)
Specifically, two hops above my cert the divergence occurs.
Why does this happen? Is there anything I can do to influence that chain (remember its the same p12 that is creating different paths)?
I should also say, I am no expert in this area. I'm a developer that muddles through these security issues when needed.
I had the same issue. Two different windows 2008 r2 servers, same certificate. After standard OS patching one of the servers was sending only the first layer of certificate trust chain (number 0), so the openssl client was failing with the message:
verify error:num=21:unable to verify the first certificate
No idea what was the root cause. I tried to
reassign certificate in IIS
reimport certificate
restart IIS
with no success. What finally helped to fix the issue was the server reboot...
Closing this out.
I'm still a little foggy on why things were working the way they did but some things made sense.
It seems the .p12 was created from a p7b that included some of the intermediate certs. One of the included intermediates was the bad one. This explains why the chain was bad on one machine.
Still not sure how I was able to see a good chain on different machine but I understand why I saw the bad one. It seems the good chain was the fluke and the bad chain should have been expected (I originally assumed the opposite).
I created a new .p12 without the intermediates. Cleaned up all the bad intermediates that were previously imported from the first .p12 in both service user and local machine stores. All seems to be working as expected now with same valid chain on all machines.

puppet master client certificate order deletion

i' ve a puppet master and a couple of slave server, and i' d like to change the hostname of the master system from a puppet manifest. To do this i change the neccessary files on the system (redhat, like /etc/sysconfig/network(master) , /etc/sysconfig/puppet(all) , /etc/puppet/puppet.conf(master)), and i delete the certificates from all the machines. If the manifest on the master will be executed first, everything fine, but if it' s executed on the slave first, it got stucked while it' ll have a new certificate already, but the master doesn' t know about it yet.
Is there any way to make a dependency on different machines between modules? Or any way to overwrite a certificate on the master from the slave machine (is it safe at all)?
At the moment i' ve this code (however it doesn' t have the deletion of the certificates on the slaves):
http://pastebin.com/gMeWPpcn
. Any other recommendations are also welcomed how to solve this master hostname change and certificate problem (i read about some mac address based certificates, but in this case it' s a no go).
I'm pretty sure there's no way around this. After you change the hostname on the master and delete the all the client certificates, your clients will no longer be able to connect to the master.
In situations like this, it's probably best to do it manually. For example:
Change the hostname on the master
Delete all the client certs (on the master)
Connect to the master from each of your clients and re-add them as you did initally

XPI signing linux no gui

I'm trying to sign an XPI on linux (no gui) using the NSS cert db (cert8.db and key3.db) i copied from another server of mine, on which I can sign XPI's just fine.
On the new box I can sign with a brand new test certificate ok, but when i try to use the old cert db, it complains with:
signtool: PROBLEM signing data (Unknown issuer)
Certutil lists the cert im trying to use with a * and the CA is present in there as well.
Is this cert db transferable between computers like this? Or are there any other files I have to setup?
TIA
Mike
im not sure if this is what you need, but here it is: http://www.mercille.org/snippets/xpiSigning.php
If the certificate chain has an intermediate CA that also needs to be there.
NSS is rather picky when it comes to the chain and also needs the certs to have been marked as trusted.