XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    self signed certificate in certificate chain

    Scheduled Pinned Locked Moved Xen Orchestra
    19 Posts 5 Posters 5.3k Views 5 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T Offline
      techjeff @olivierlambert
      last edited by

      olivierlambert thank you for that information!

      I have been creating a unique certificate for each host, and that explains why the requests have been failing / hanging. Based on what you're saying, I ought be making one certificate that covers all hosts in a pool and applying that same certificate and key to each host, yes?

      For example, a certificate with CN="Example Domain XCP-NG Hosts" and SANs xcp-ng-1.example.com, 10.0.10.11, xcp-ng-2.example.com, 10.0.10.12, etc.

      I'll give that a try and follow up.

      1 Reply Last reply Reply Quote 0
      • olivierlambertO Online
        olivierlambert Vates 🪐 Co-Founder CEO
        last edited by

        I think that would be needed to be able to connect to each host of the pool, yes 🙂 Please keep us posted!

        T 1 Reply Last reply Reply Quote 0
        • T Offline
          techjeff @olivierlambert
          last edited by techjeff

          olivierlambert Today I created a new key and certificate as per the official documentation and I added SANs for the hostname and IP address of each xcp-ng hosts in my pool. I used XO's Replace existing certificate button, I saw the correct fingerprint apear on both hosts, I restarted the toolstack on both hosts, and I verified via cli on one of the hosts that the fingerprint of /ext/xensource/xap-ssl.pem matches that which is displayed in xo.

          Nonetheless, I get the same results in the two instances of xo: the clone of the snapshot I took before updating (on commit feat: release 5.63.0 (#5925)) connects just fine with Unauthorized Cerificates disabled, and the original instance that was updated will only connect when Unauthorized Certificates is enabled, otherwise it gives the error self signed certificate in certificate chain.

          I then ran the update tool again and it did indeed move to what is as of this writing the latest commit at https://github.com/vatesfr/xen-orchestra: [info] Updating xen-orchestra from 'abcabb736' to '9ceba1d6e' however, I still get the same behavior.

          I'm not sure what, but something happened after 5.63.0 that is causing xo to reject the certificate even though I'm using the same certificate chain as before.

          1 Reply Last reply Reply Quote 0
          • olivierlambertO Online
            olivierlambert Vates 🪐 Co-Founder CEO
            last edited by

            Pinging julien-f

            T 1 Reply Last reply Reply Quote 0
            • T Offline
              techjeff @olivierlambert
              last edited by techjeff

              olivierlambert julien-f Today I was reviewing Web UI Certificates for XCP-NG Host I found that when I was configuring XO to use my custom CA, I did a copy/pasta job into /etc/systemd/system/xo-server.service.d/ca.conf and didn't actually update it to point to my actual CA certificate.. so that file was actually configured with the default: Environment=NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/my-cert.crt which obviously will not work. It must have been late into the evening when I added this file.

              In any case, once I fixed this to correctly point to my CA certificate, ran systemctl daemon-reload, and systemctl restart xo-server.service, I am now properly able to connect with "Unauthorized Certificates" disabled.

              For the record, I did ultimately create one certificate with a general Common Name and then added a Subject Alt Name for every IP Address and Hostname used by all 3 of my xcp-ng hosts, e.g.

              DNS=xcp-ng-1.mgmt.intangible.home.arpa
              IP=10.0.10.11
              DNS=xcp-ng-1.san.intangible.home.arpa
              IP=10.0.60.11
              DNS=xcp-ng-2.mgmt.intangible.home.arpa
              IP=10.0.10.12
              DNS=xcp-ng-2.san.intangible.home.arpa
              IP=10.0.60.12
              

              etc..

              Since we were not certain whether each host needed the same certificate containing all of the SANs for all hosts or if creating individual certificates for each host would be sufficient, I plan on creating test certificates that are unique to each host, deploying these certificates, and then reporting back whether installing unique certificates per host works as I originally suspected it would.

              Also for the record, I'm currently working on Xen Orchestra, commit afeb2, xo-server 5.107.5, and xo-web 5.109.0.

              T 1 Reply Last reply Reply Quote 0
              • T Offline
                techjeff @techjeff
                last edited by techjeff

                olivierlambert julien-f

                As a final confirmation, since my last message, I generated one certificate for each of my 3 hosts. Each certificate only contained the DNS and IP SANs for that specific host. I then deployed each of the 3 certificates to their respective hosts using xe host-server-certificate-install without issue.

                Like I mentioned in my previous post, I am not not getting self signed certificate in certificate chain because I have properly configured xo-server to trust my CA cert.

                However, I am now back to getting the endless Xapi#getResource /rrd_updates (on xcp-ng-1) 0% tasks every minute that last for ~24 hours (unless I run xe-toolstack-restart to clear the list.)

                I then redeployed my "Pool Certificate" (contains all DNS/IP SANs for all hosts) to each host from the master, executed xe-toolstack-restart and now all is working without issue. I must admit, this is much easier to maintain than trying to maintain 1:1 cert:host.

                In conclusion, as you mentioned in your previous reply olivierlambert, it does appear that a person must sign 1 certificate per pool and that certificate must be configured with Subject Alternate Names for each DNS name and IP used by all hosts in the pool.

                Thanks again for working with me on this!

                1 Reply Last reply Reply Quote 1
                • olivierlambertO Online
                  olivierlambert Vates 🪐 Co-Founder CEO
                  last edited by

                  Thanks a lot for your detailed and valued feedback!

                  If our doc lack details about this input, we should probably improve it. What do you think stormi ?

                  1 Reply Last reply Reply Quote 0
                  • stormiS Offline
                    stormi Vates 🪐 XCP-ng Team
                    last edited by

                    Yes, this should definitely be added. techjeff, since the subject is fresh in your mind, would you mind contributing an improvement to the guide?

                    T 1 Reply Last reply Reply Quote 0
                    • T Offline
                      techjeff @stormi
                      last edited by

                      stormi Sure, I would be happy to do that. In which repo are these guides stored?

                      stormiS 1 Reply Last reply Reply Quote 0
                      • stormiS Offline
                        stormi Vates 🪐 XCP-ng Team @techjeff
                        last edited by stormi

                        techjeff There's a link at the bottom of each page which will open a text editor directly on github. You can also manually create a PR on the repository the link leads to if you prefer.

                        T 1 Reply Last reply Reply Quote 1
                        • T Offline
                          techjeff @stormi
                          last edited by

                          stormi olivierlambert Please see my submitted PR and please provide feedback.

                          H 1 Reply Last reply Reply Quote 2
                          • T Offline
                            techjeff @olivierlambert
                            last edited by

                            olivierlambert as pointed out by psafont on my PR #216,

                            I believe there is no such technical requirement, when following a redirect the
                            new request should be done against a different IP/host and the TLS connection renegotiated with that host, meaning none of the hosts' certs should have identifying information from the other one.

                            I think I need to dive deeper and hope to find an a log message related to the lingering Xapi#getResource /rrd_updates tasks.

                            1 Reply Last reply Reply Quote 1
                            • H Offline
                              HeMaN @techjeff
                              last edited by

                              techjeff said in self signed certificate in certificate chain:

                              stormi olivierlambert Please see my submitted PR and please provide feedback.

                              I followed the guides on the site to install my custom certificates (self signed) to my new xcp-ng servers (homelab) and installed the CA cert in XO (from sources).

                              Came across this post when having issues with deploying self signed certificates and subsequent rrd update errors, and saw there is additional info mentioned in the PR for the Guide section on the website.

                              Is it correct the PR is not published yet to the website, or am I looking into the wrong places?

                              T 1 Reply Last reply Reply Quote 0
                              • T Offline
                                techjeff @HeMaN
                                last edited by techjeff

                                HeMaN You're correct that no changes have been published yet.

                                We were under the impression that we had found an undocumented requirement, but I was reminded that giving each host the same certificate is not the best practice. xcp-ng should be able to handle each host having its own certificate as long as their respective certificate authorities are trusted.

                                In any case, I need to do some more testing to narrow down the exact cause of the issues that I was seeing. I have been working a systemd service and timer with a few supporting scripts that automatically renew certificates by making ACME requests to my local, private CA, specifically adding support for additional SANs (previous iterations just used the system's FQDN).

                                Specifically, I want to test each server with SANs that correspond to each of it's IP addresses and FQDNs, deploy them using xe host-server-certificate-install, then perform packet captures as needed to determine why the Xapi#getResource /rrd_updates (on xcp-ng-1) 0% task is getting stuck.

                                So far, life has gotten a bit in the way, so I haven't dedicated the time to testing this, but I hope to get back to this soon.

                                1 Reply Last reply Reply Quote 3
                                • E Offline
                                  exr90
                                  last edited by

                                  FWIW I just got bit by this same thing, spending half a day yesterday kicking the wall. I think I got about 2/3 of the way just by trial and error on the cert's.

                                  Would love to see this doc'd with the proper method, using an in-house local CA (not a public CA).

                                  1 Reply Last reply Reply Quote 1
                                  • First post
                                    Last post