@Bryanvh No problem 
The issue you encountered wasn't very clear. Therefore, I've proposed a change to the XAPI to make the error more explicit (this will likely be implemented in future XAPI releases).
So instead of SSL Certification failure the message will be: POOL_JOINING_MASTER_CERTIFICATE_NOT_IN_POOL_BUNDLE.
Thank you very much for your patience and for bringing this issue to our attention.
References:
https://github.com/xapi-project/xen-api/pull/7112
@Andrew I did suspect that would be sufficient, but we need to think at feature level, and as mentionned there is no such thing we could do "quickly" for linux and other OSes. I anyway did a brain dump of my investigation before posting my previous message and we do now have an entry in the roadmap for it, which was not the case previously.
Unfortunately, that's not trivial.
Currently in windows, the PV driver reads that info inheritance from the network setting at startup and applies it, it would not allow live modification.
On the other hand, the Linux driver does not do that, therefore it would not be at feature parity. So it would likely be possible to have a "quick and dirty" implementation that works only at boot and only on windows, that would help your case indeed, but that's not a great product feature 
We will discuss that internally and see what can be added to the roadmap and to which depth we want to dig that hole as well as this can go pretty far, we'll need to split that in smaller steps to be able to deliver something in a timely fashion.
@Bryanvh Looking at the code, I saw that an exchange was taking place via this certificate.
So when you told me that the master certificate was missing, I tried to put myself in the same situation as you (by removing the certificate) and trying to join the pool.
Having encountered the same error as you, I determined that running these commands fixed the problem.
Indeed, I think the upgrade from 8.2 to 8.3 is the cause. To be more precise, a change occurred in the XAPI during the certificate exchange in version 8.2, and I think it's possible that your 8.2 host wasn't up to date when it upgraded to 8.3 (I'm not sure).
In any case, I'm glad your problem is solved.
@Bryanvh I think I've managed to reproduce the issue. The fact that the master's certificate is missing from /etc/stunnel/certs-pool/ seems to be the problem.
On the master, run xe host-refresh-server-certificate host=$(hostname) and then xe pool-certificate-sync.
Then, if you run ls -l /etc/stunnel/certs-pool, you should see a certificate with the same name as your master's UUID. It should end with .pem. If it ends with .new.pem, I recommend copying the certificate, removing the .new (which can apparently cause problems).
You should then be able to join the pool from your host.
I hope this worked. Please let me know if it works.
Respectfully,
@Rod-G Hello,
We are indeed aware of this vulnerability on the Kernel. But I still thank you for this message, it shows that the community is attentive to the subject of safety on our products.
I also fixed the PoC, and I managed to reproduce the flaw. I also took the opportunity to start making a fix.
You highlighted it, but this security flaw is mitigated by respecting our best practices as well as the fact that we are a hypervisor which must keep restricted access.
For vulnerabilities like CopyFail, DirtyFrag, Fragnesia, we have just released the fix. The blog post is here: https://xcp-ng.org/blog/2026/06/02/june-2026-updates-1-for-xcp-ng-8-3-lts/
This being similar, there is a good chance that we will fix it and give the same severity.
I would also like to anticipate the question of why a fix has not already been included in the security update released today. Our procedure aims for security but also stability, we pass a CI to avoid regressions, as well as a user testing period. With a deadline of less than a day, this would not have been possible.
Just a quick general reminder, but if you find a security flaw and want to report it to us, the best thing to do is to contact our email: security [at] this domain name.
I hope I was able to give you the most complete answer, don't hesitate if anything is missing.
Respectfully,
@Bryanvh Thank you for your feedback,
Your previous certificates look correct. I have not been able to reproduce the issue on my side, but I will try to diagnose it based on the code.
[MASTER]
I have a few preliminary commands. The first one is to retrieve the MASTER_UUID:
cat /etc/xensource-inventory | grep INSTALLATION_UUID | cut -d'=' -f2 | tr -d "'"
Then we can compare fingerprints between the master certificate and the one stored for the pool:
openssl x509 -in /etc/xensource/xapi-pool-tls.pem -noout -fingerprint -sha256
openssl x509 -in /etc/stunnel/certs-pool/{MASTER_UUID}.pem -noout -fingerprint -sha256
(please replace {MASTER_UUID} with the value retrieved above)
Normally, both fingerprints should match.
Also check that the CA bundle exists and is not empty:
ls -l /etc/stunnel/xapi-pool-ca-bundle.pem
If you previously ran:
xe host-refresh-server-certificate
you should probably run:
xe pool-certificate-sync
[JOINER]
Based on the code, the first phase has already been completed. You should therefore have files under /etc/stunnel/certs-pool/, including the master certificate:
openssl x509 -in /etc/stunnel/certs-pool/{MASTER_UUID}.pem -noout -fingerprint -sha256
[Additional checks]
Are all hosts synchronized to the same NTP server? date & timedatectl
Are all hosts fully updated to XCP-ng 8.3 and rebooted after updates?
Do you see the same error when joining the pool using XCP-ng (via Console or CLI) instead of Xen Orchestra?
Is there any more detailed error in /var/log/xensource.log ?
How many hosts are in your pool?
Is stunnel running correctly on all hosts? systemctl status stunnel@xapi
Do certificate chains validate correctly?
openssl verify -CAfile /etc/stunnel/xapi-pool-ca-bundle.pem /etc/stunnel/certs-pool/{MASTER_UUID}.pem
Respectfully,
@semarie I'll try to investigate to help you.
Is it possible to run:
stat /etc/xensource/xapi-pool-tls.pemopenssl x509 -in /etc/xensource/xapi-pool-tls.pem -noout -textstat /etc/xensource/xapi-ssl.pemopenssl x509 -in /etc/xensource/xapi-ssl.pem -noout -text(This file must exist; if not, I'd like the output of cat /etc/stunnel/xapi.conf.)
And I'd like the same output for /etc/xensource/xapi-ssl.pem.
If the certificate for /etc/xensource/xapi-pool.tls.pem has expired or it's empty, you can run:
xe host-refresh-server-certificate host=$(hostname)
If the certificate for /etc/xensource/xapi-ssl.pem has expired or it's empty, you can run:
xe host-emergency-reset-server-certificate
After running one of the two commands above, I recommend to do: xe-toolstack-restart
(This should indeed restart the stunnel@xapi.service)
I hope this helps.