<div dir="ltr"><div>I have been working on a custom Airship site definition (starting from the Airsloop reference), and am running into an issue during the creation of the genesis.sh script where the certificates included in the bundle still have the default names (airsloop-control-1, etc) and default IP addresses instead of those specified in my pki-catalog.yaml file.</div><div><br></div><div>After running `sudo tools/airship promenade generate-certs \<br>  -o /target/${NEW_SITE}_certs /target/${NEW_SITE}_collected/*.yaml` and manually inspecting the file by extracting the cert data and doing an openssl read, I see that the certificates and SANs are correct. Similarly when I inspect the collected yaml document after running the pegleg collect process, I find that the certificates are correct.</div><div><br></div><div>Despite this, when running `sudo tools/airship promenade build-all --validators -o /target/${NEW_SITE}_bundle /target/${NEW_SITE}_collected/*.yaml` I can see the log line outputs where the certificates are added to the bundle, and the corresponding md5sums match those of the default certificates. When I execute the genesis script it is these default certificates that are extracted to /etc/genesis/ and as a result the etcd containers are unable to join a cluster together, failing with an error of:</div><div>"2019-09-12 06:39:15.264601 W | rafthttp: health check for peer b9e987dd1344ab69 could not connect: x509: certificate is valid for 10.22.72.21, 127.0.0.1, 10.96.0.2, not 10.9.22.21".</div><div><br></div><div>I've looked everywhere I can think of to try to identify where these certificates are being re-introduced (having carefully removed all copies of them before I execute the build-all process), but am unable to track them down. Has anyone run into this issue before or know what may be happening?</div><div><br></div><div>-Hilbert<br></div></div>