f5-declarative-onboarding
f5-declarative-onboarding copied to clipboard
RFE - Regen Device Cert
It is common practice to regenerate the device cert with the CN as the hostname. This needs to happen before HA, so the new cert is used HA/DSC/iQuery communications as needed. This is also a big plus from a security perspective since it would help promote the generation of a new unique cert/key pair as part of the deployment.
It would be nice, at a minimum, to have a flag, possibly in the tenant class, like "regenDeviceCert": true/false, that would regen the device cert with CN=hostname. Or maybe a new class to set import a cert/key, or set certificate details like more subject information, key-length, and days?
Commands I use for this: # generate new cert/key, overwriting default openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -subj "/CN=$HOSTNAME" -keyout /config/httpd/conf/ssl.crt/server.key -out /config/httpd/conf/ssl.crt/server.crt
# Add cert to trusted cert stores - This is necessary for proper device trust and iquery usage. cat /config/httpd/conf/ssl.crt/server.crt >> /config/big3d/client.crt && cat /config/httpd/conf/ssl.crt/server.crt >> /config/gtm/server.crt
# restart httpd to pick up new cert/key tmsh restart sys service httpd
Would having the ability to include certificates in the DO declaration satisfy your use case?
Potentially, however, I think it would make more work on the end user. This would allow for enterprises to supply CA signed certs and KEYs. Which is good from an enterprise security perspective (mostly), but it definitely complicates the environment with a DNS iquery mesh. Where certs would have to be updated in a very specific way, or risk loosing iquery and supportin F5 DNS infrastructure.
On bigips, it is recommended to have self-signed device certs with a 10 year expiration for the best iquery stability.
I think both (user provided and self-signed on box) would be best for options. My big hesitation is that whatever is sending the declaration would have to generate and/or manage device certificates/keys, which is another layer of complexity from just building and sending the declaration.
I guess this is something that is already being done with as3 and public application certs, but I feel that is unnecessarily complicates things since the device cert should be self-signed with a 10 year expiration.
Thank you for clarifying your use case. I agree that it would make sense to have this feature alongside the ability to upload certificates. Do you happen to have some documentation handy for those self signed certificate recommendations?
I have added this feature request to our internal product backlog as AUTOTOOL-957.
Hi @dstokesf5 when this feature will released ?
@tizianorosato-gr This item is in our product backlog, but not yet on the road map. If this feature request is urgent, please open a support case (https://support.f5.com/csp/article/K2633) to get it more attention and escalate the priority of it.
I too would like to see the ability to import device certificates via DO. That would allow me to use certificates/keys issued from my PKI environment, rather than use self-signed.
Added to EPIC. This might be blocked. Flagging as a SPIKE
Update on this task for the next Sprint
They are Ok with providing Cert and Key with the DO Declaration.
- That would be great if the certificate would be copy to GTM, on initial onboarding and if DNS is provisioned.
- he is very aware that playing with GTM cert after the first deployment could be tricky and break existing DNS Mesh and even in the Non Automated world, DNS cert operations need to be carefully planned.