xcp
xcp copied to clipboard
letsencrypt support
have acme.sh built in to xcp-ng, this would allow xen-orchestra with support to install a host valid cert without having to upload one in xen-orchestra UI but still have the option to do so
I think there's some work on XAPI side to have an ACME thing. Pinging @psafont about this.
I'm sorry to say that there are no plans in Citrix to support the ACME protocol or even support CSRs in some way to supply certificates for the host servers.
Damn. Maybe we could provide some work on our side via a PR? If there's a "good" way to do it, we'll be happy to help :+1:
I have written a deploy hook for acme.sh
that I was considering to publish. Is that something that would help?
I have written a deploy hook for
acme.sh
that I was considering to publish. Is that something that would help?
At the very least, this could be useful to other users, so feel free to share it.
I have created a repository where you can look at the deploy hook. You can find the deploy hook for XCP-ng here. I look forward to any suggestions that you can make to improve it.
I have created a repository where you can look at the deploy hook. You can find the deploy hook for XCP-ng here. I look forward to any suggestions that you can make to improve it.
Has anyone tried it out yet? Is anyone willing to suggest any improvements? If not, I may start a pull request to include it in acme.sh
.
Thanks, I'll follow it
@windgmbh could you write some hints about the certificate issueing part? Especially, how acme.sh has to be run, what parameters need to be set, to enable the retrieval,and regular renew of the certificate for the XAPI service.
When you install it, it sets up a crobjob to renew it as the user that installed it and when it it gets it on the first the you can set post renew hooks to restart a service etc. Normally you use acme.sh to do DNS challenge which will use API tokens etc from your domains DNS provider like cloudflare for example as it then puts a txt record to say you own the domain basically and then generates the cert. Hope that explains what you wanted to know?
From: Gergely Nagy @.> Sent: Tuesday, April 13, 2021 9:13:43 PM To: xcp-ng/xcp @.> Cc: J.Townsend @.>; Author @.> Subject: Re: [xcp-ng/xcp] letsencrypt support (#452)
@windgmbhhttps://github.com/windgmbh could you write some hints about the certificate issueing part? Especially, how acme.sh has to be run, what parameters need to be set, to enable the retrieval,and regular renew of the certificate for the XAPI service.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/xcp-ng/xcp/issues/452#issuecomment-819022557, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA3V2QWUHQLKV2LDET3KTTTTISQXPANCNFSM4TVXGSLQ.
Oh... DNS challenge, i was hoping you found a way for http-challenge. The issue with DNS challenge is, there are lot of DNS providers in my country, where you have no API but a webUI for zone management, or more worse, you have to write some supportguy to carry out any zone modification.
The only thing I would suggest if it is feasible is to move to someone like cloudflare where you can do it via an API so you can use DNS challenge
From: Gergely Nagy @.***> Sent: Tuesday, 13 April 2021, 21:50 To: xcp-ng/xcp Cc: J.Townsend; Author Subject: Re: [xcp-ng/xcp] letsencrypt support (#452)
Oh... DNS challenge, i was hoping you found a way for http-challenge. The issue with DNS challenge is, there are lot of DNS providers in my country, where you have no API but a webUI for zone management, or more worse, you have to write some supportguy to carry out any zone modification.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/xcp-ng/xcp/issues/452#issuecomment-819045859, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA3V2QQCB42XOGOSO6ARRN3TISVBTANCNFSM4TVXGSLQ.
Oh... DNS challenge, i was hoping you found a way for http-challenge.
acme.sh
can be used for HTTP challenges as well. The HTTP challenge is implemented with socat
so you may need root Permissions (which you will need for xe
anyway).
@windgmbh could you write some hints about the certificate issueing part?
I dont have the particular command on hand, but for a HTTP challenge it must have been something like:
./acme.sh --issue --standalone -d xcp.example.com --days 60 --deploy-hook xcp-ng
Just drop the xcp-ng.sh
into the deploy
folder of your current acme.sh
installation. The --days
flag should trigger renewal after 60 days. The --standalone
flag uses the HTTP challenge with socat
. When you have issued a certificate you can use --deploy
instead of --issue
. When you are trying out some settings for issuing certificates I recommend to use --staging
to prevent exceeding Let's Encrypt's limits.
acme.sh
has actually a lot of different settings, runs on basically any system that ships with bash
and is very reliable. Just consider their documentation and you might be able to find a solution for your challenge.
Can also use certbot which by default uses http method it can do DNS as well but you then need to get the correct module for that. But it requires it being on the internet for that which is a bad idea from a security point of view
From: windgmbh @.> Sent: Wednesday, April 14, 2021 12:12:33 PM To: xcp-ng/xcp @.> Cc: J.Townsend @.>; Author @.> Subject: Re: [xcp-ng/xcp] letsencrypt support (#452)
Oh... DNS challenge, i was hoping you found a way for http-challenge.
acme.sh can be used for HTTP challenges as well. The HTTP challenge is implemented with socat so you may need root Permissions (which you will need for xe anyway).
@windgmbhhttps://github.com/windgmbh could you write some hints about the certificate issueing part?
I dont have the particular command on hand, but for a HTTP challenge it must have been something like:
./acme.sh --issue --standalone -d xcp.example.com --days 60 --deploy-hook xcp-ng
Just drop the xcp-ng.sh into the deploy folder of your current acme.sh installation. The --days flag should trigger renewal after 60 days. The --standalone flag uses the HTTP challenge with socat. When you have issued a certificate you can use --deploy instead of --issue. When you are trying out some settings for issuing certificates I recommend to use --staging to prevent exceeding Let's Encrypt's limits.
acme.sh has actually a lot of different settings, runs on basically any system that ships with bash and is very reliable. Just consider their documentationhttps://github.com/acmesh-official/acme.sh/wiki and you might be able to find a solution for your challenge.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/xcp-ng/xcp/issues/452#issuecomment-819437727, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA3V2QTVEBCH7RFSIEMPSLTTIV2CDANCNFSM4TVXGSLQ.
The obstacle in my mind was, how to occupy port 80, but let xapi live its life. Just finished a successful verification, and signing with acme.sh, and the working solution was so simple:
- xapi does itself serve port 80 normal http content from
/opt/xensource/www
- check the hostname, you want to sign with Let's Encrypt, that is shows you the
Welcome To XCP-Ng
over http:// - get acme.sh on the dom0
- issue the cert in webroot mode:
acme.sh --issue -d your.xcp-ng.host -w /opt/xensource/www
- assuming the
xcp-ng
deploy hook is in place the above could be done so:
acme.sh --issue -d your.xcp-ng.host -w /opt/xensource/www --deploy-hook xcp-ng
@windgmbh i tested manually the command here https://github.com/windgmbh/acme.sh/blob/master/deploy/xcp-ng.sh#L27
and the resulting xapi-ssl.pem seems to contain the server cert twice if certificate-chain="${_cfullchain}"
is used, and the right content can be achieved by changing that to certificate-chain="${_cca}"
@windgmbh i tested manually the command here https://github.com/windgmbh/acme.sh/blob/master/deploy/xcp-ng.sh#L27 and the resulting xapi-ssl.pem seems to contain the server cert twice if
certificate-chain="${_cfullchain}"
is used, and the right content can be achieved by changing that tocertificate-chain="${_cca}"
Thanks for noticing that. I have updated the commit in that regard.
Issuing the certificate in Webroot mode is probably the way to go, if port 80 on an internet facing network interface is occupied. Maybe less elegant but mentionable are two other methods:
- Use
--pre-hook
and--post-hook
to stop and start the service before and after obtaining certificates. - Specifiy a different
--http-port
for the--standalone
ACME challenge. Then you forward all traffic that does not need to have access to port 80 to that specific port withiptables
.