You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since 2.18.0 x509_certificate fails to recognize that the existing certificate already fulfills the "...not_before" / "...not_after" conditions and regenerates the certificate. A quick test in my setup has shown that the newly generated CA certificate still can confirm certificates issued with the previous CA certificate - even when the serial number of the CA certificate changed. However, it's a creepy feeling and I would prefer the module to be idempotent again.
Fedora 40, I provide a script to reproduce the error behavior below.
STEPS TO REPRODUCE
I created a demo script which shows the difference between 2.17.1 and 2.19.0 in a container: demo.zip
You can see it already from the color of the output that 2.19.0 regenerates the certificate, but the md5sums show that the resulting new certificate also differs from the original one.
Here is the task which should be idempotent the second time it's executed:
I expect the behavior as shown with community.crypto 2.17.1: if the existing certificate already fulfills all requirements it should not get regenerated.
ACTUAL RESULTS
Since community.crypto 2.18.0 the certificate gets regenerated and the module is not idempotent anymore.
The text was updated successfully, but these errors were encountered:
Thanks for the fix and sorry for my mistake with 2.18.0 - I thought I saw 2.18.0 when I first stumbled over the bug, but I should have double checked it.
SUMMARY
Since 2.18.0
x509_certificate
fails to recognize that the existing certificate already fulfills the "...not_before" / "...not_after" conditions and regenerates the certificate. A quick test in my setup has shown that the newly generated CA certificate still can confirm certificates issued with the previous CA certificate - even when the serial number of the CA certificate changed. However, it's a creepy feeling and I would prefer the module to be idempotent again.ISSUE TYPE
COMPONENT NAME
x509_certificate
ANSIBLE VERSION
COLLECTION VERSION
CONFIGURATION
OS / ENVIRONMENT
Fedora 40, I provide a script to reproduce the error behavior below.
STEPS TO REPRODUCE
I created a demo script which shows the difference between 2.17.1 and 2.19.0 in a container:
demo.zip
You can see it already from the color of the output that 2.19.0 regenerates the certificate, but the md5sums show that the resulting new certificate also differs from the original one.
Here is the task which should be idempotent the second time it's executed:
EXPECTED RESULTS
I expect the behavior as shown with community.crypto 2.17.1: if the existing certificate already fulfills all requirements it should not get regenerated.
ACTUAL RESULTS
Since community.crypto 2.18.0 the certificate gets regenerated and the module is not idempotent anymore.
The text was updated successfully, but these errors were encountered: