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
Private key generation currently does not work in the v4 of the library. This can be traced back to juju not writing the content of the secret until the hook successfully finishes executing (Let's call this new value private-key-1). When the key is first regenerated the _cleanup_certificate_requests and _send_certificate_requests will not work as expected because the value of the private key will still be the old value and thus no changes will take effect.
If you regenerate the private key for a second time. The certificates generated will use the private-key-1 value to clean and send new CSRs then when the hook finishes execution the value will be updated to private-key-2.
When the provider issues certs got the client they will be signed by private-key-1. On CertificateAvailable the get_assigned_certificates function will fail because none of the certificates actually match the private key that now ahs private-key-2 value.
unit-charmed-etcd-0: 10:45:22 WARNING unit.charmed-etcd/0.juju-log peer-certificates:3: Public key numbers between CSR and key do not match
unit-charmed-etcd-0: 10:45:22 WARNING unit.charmed-etcd/0.juju-log peer-certificates:3: Certificate does not match the private key. Ignoring invalid certificate.
File "/var/lib/juju/agents/unit-charmed-etcd-0/charm/src/events/tls.py", line 108, in _on_certificate_available
raise TLSMissingCertificateOrKeyError("Missing certificate or private key")
common.exceptions.TLSMissingCertificateOrKeyError: Missing certificate or private key
Additional context
Big thank you to @saltiyazan for helping investigate and track the bug.
The text was updated successfully, but these errors were encountered:
Bug Description
Private key generation currently does not work in the v4 of the library. This can be traced back to juju not writing the content of the secret until the hook successfully finishes executing (Let's call this new value
private-key-1
). When the key is first regenerated the_cleanup_certificate_requests
and_send_certificate_requests
will not work as expected because the value of the private key will still be the old value and thus no changes will take effect.If you regenerate the private key for a second time. The certificates generated will use the
private-key-1
value to clean and send new CSRs then when the hook finishes execution the value will be updated toprivate-key-2
.When the provider issues certs got the client they will be signed by
private-key-1
. OnCertificateAvailable
theget_assigned_certificates
function will fail because none of the certificates actually match the private key that now ahsprivate-key-2
value.To Reproduce
Environment
I am running:
3.6.1-genericlinux-amd64
5.21.2 LTS
Relevant log output
Additional context
Big thank you to @saltiyazan for helping investigate and track the bug.
The text was updated successfully, but these errors were encountered: