When starting the libvirtd service, I encountered the error: "The server certificate /etc/pki/libvirt/servercert.pem has expired."

[LiuYanHao789]

ISSUE TYPE

• Other

COMPONENT NAME

Cert

CLOUDSTACK VERSION

cloudstack 4.18.1.0

CONFIGURATION

OS / ENVIRONMENT

Centos 7.9

SUMMARY

When starting the libvirtd service, I encountered the error: "The server certificate /etc/pki/libvirt/servercert.pem has expired." The certificate in question originates from /etc/cloudstack/agent/cloud.crt, which is valid for one year. What should I do when the certificate expires? Should I create a self-signed certificate to replace it? If I do, will there be any impact due to context or dependencies? Or is there another solution?

STEPS TO REPRODUCE

# systemctl restart libvirtd 
error: "The server certificate /etc/pki/libvirt/servercert.pem has expired"
# ll /etc/pki/libvirt/servercert.pem
/etc/pki/libvirt/servercert.pem -> /etc/cloudstack/agent/cloud.crt

I can see that it's a symbolic link, with the source path being /etc/cloudstack/agent/cloud.crt. I checked the certificate's validity period using the command:

# openssl x509 -in /etc/cloudstack/agent/cloud.crt -noout -dates
notBefore=Jul 12 19:44:27 2023 GMT
notAfter=Jul 12 07:44:27 2024 GMT

EXPECTED RESULTS

I can see that it's a symbolic link, with the source path being /etc/cloudstack/agent/cloud.crt. I checked the certificate's validity period using the command:

# openssl x509 -in /etc/cloudstack/agent/cloud.crt -noout -dates
notBefore=Jul 12 19:44:27 2023 GMT
notAfter=Jul 12 07:44:27 2024 GMT

It turns out the certificate has expired, which caused the error when I tried to restart the libvirtd service today. Should I create a self-signed certificate to replace it? If I do, will there be any impact due to context or dependencies? Or is there another solution?

ACTUAL RESULTS

[boring-cyborg[bot]]

Thanks for opening your first issue here! Be sure to follow the issue template!

[weizhouapache]

You can try the following steps

1. backup and then delete the cloud.* files from /etc/cloudstack/agent/ directory
2. change auth strictness global setting to false (ca.plugin.root.auth.strictness) in cloudstack temporarily
3. set listen_tcp=1/listen_tls=0/vnc_tls=0 in libvirtd.conf, and restart libvirtd
4. restart cloudstack agent on the KVM host, and once it's connected, in CloudStack go to the UI-> infra ->host -> select the specific host -> click button to re-provision certficates (this will resetup the cloud.jks and certificates on the kvm host)
5. finally, reset the ca.plugin.root.auth.strictness back to true

[LiuYanHao789]

感谢大佬！！！国人牛逼，但是我的这个ca.plugin.root.auth.strictness，我发现默认就是false关闭的，没有打开。这个东西在生产环境会有啥影响吗？

[rohityadavcloud]

@LiuYanHao789 I don't understand your last comment. By re-provisioning certificate on all hosts and turning auth strictness to true is enough to secure your production env. See if you can upgrade to the most recent 4.18 release and have ca.framework.cert.automatic.renewal set to true, or increase ca.framework.cert.validity.period to a high value.

[LiuYanHao789]

I didn't realize that the ca.framework.cert.automatic.renewal parameter in my CloudStack 4.18.1.0 version was set to false until I encountered a certificate expiration issue. I hadn't made any changes to this setting before, so it might have been disabled by default. Should I enable it by setting it to true?

[rohityadavcloud]

Yes you may review and configure these settings. As far as I can check the code, it's supposed to be enabled by default for 4.18 - https://github.com/apache/cloudstack/blob/4.18/api/src/main/java/org/apache/cloudstack/ca/CAManager.java#L61 it is possible you were on an older version where it may not exist or something got changed during transition.