I tried to use a letsencrypt cert on our xmpp server which runs openfire 4.0.1. As i tried to import the private key and certificate I got the following error:
“There was an error while trying to import the private key and signed certificate. Internal server error: The supplied certificate chain does not cover the domain of this XMPP service.”
The cert is vaild for multiple subdomains like server.domain.org and xmpp.domain.org. The server is running under the xmpp.domain.org domain. I had to fill out the following boxes:
Pass Phrase used for creating Private Key: (i let this field empty)
Content of Private Key file: -----BEGIN PRIVATE KEY-----…-----END PRIVATE KEY-----
Content of Certificate file:-----BEGIN CERTIFICATE-----…-----END CERTIFICATE-----
What could be wrong in my config?
Its an known error in version 4.0.0 on openfire and probably get fixed in 4.1.0.
Try maybe to use fullchain.pem instead of cert.pem ?
Already tried - no sucsess. I tried to use the full-Fullchain file (looks like --BEGIN…END…BEGIN…END—) and only the first or the last part.
I don’t use xmpp, but I’d try generating a self signed cert in xmpp ( I believe it can do that ) and then comparing what it actually stores with what you have to identify what it needs where.
Is it possible that it wants the private key and cert to be combined into a single file? There’s some server software that does that, and it’s not a combination that we provide out of the box. (e.g.,
cert.pem in one file, and
chain.pem as the other one)
I experience the same issue.
I installed the Intermediary CA in OpenFire trust store so it will recognize Letsencrypt.
The way they import a certificate is two parts:
- “Please provide the PEM representation of the private key that should be used to identify Openfire.”
So that’s where I paste the contents of privkey.pem from -----BEGIN PRIVATE KEY----- to -----END PRIVATE KEY-----
- “Please provide the PEM representation of the certificate chain that
represents the identity of Openfire. Note that the certificate chain
must be based on the private key provided above.”
That’s where I try pasting cert.pem and fullchain.pem - both are not accepted.
"There was an error while trying to import the private key and signed certificate.
Internal server error: The supplied certificate chain does not cover the domain of this XMPP service"
The error message is quite clear.
I think the issue is that a certificate must be valid for the “XMPP domain” which is often NOT the FQDN of the server in question.
You could have a bunch of servers that serve the XMPP domain of company.org
The FQDN of the servers may be alpha.chat.company.org etc. My letsencrypt cert was for the FQDN of the server.
I will try recreate one and ask it to issue me a cert for two common names: alpha.chat.company.org and company.org
That might work.
Recreated a cert that covers alpha.chat.company.org (the openfire server’s FQDN) as well as company.org (the XMPP domain) and the certificate installed.
The workaround for me was to temporarily edit my Openfire server properties to set the value of xmpp.domain to the FQDN of the server AND THEN RESTART OPENFIRE (!).
Then import the cert. It will now pass validation and go live. Now change the value of xmpp.domain back and restart openfire again. All working now and my clients seem to connect securely. I do notice that s2s connections to some services i.e. gmail.com are not secured. And xabber.de seem to not talk to our server anymore. Maybe they don’t recognize letsencrypt yet.
Either way, this is cool. Now I need to think of ways to automate renewals with a bash script and keytool perhaps.
This is my openfire renewal script, but I only tested it with 3.10.x.
I read about several changes on certificate handling in openfire 4.x, so I did not update and test this until now.
Thanks for taking the time to track this issue. We’re currently tracking it in our issue tracker as https://igniterealtime.org/issues/browse/OF-1100
The problem appears to be caused by a failure in Openfire to identify subjectAltName entries of the certificate. The identifiers of an XMPP server are preferably obtained from a certificate using a subjectAltName entry of type otherName with an ASN.1 Object Identifier of “id-on-xmppAddr”. When such entry does not exist, Openfire currently falls back to the Common Name. Instead, it should also evaluate subjectAltName entries of the DNS type. This problem was probably introduced in Openfire 4.0.0. We’re aiming to fix it in 4.1.0
Thank you for you’re reply. It would be gladful if it is solved in the next version
tested your script on 4.0.2 and it works fine. in 4.x you can have different keystores and truststores for different aspects of the server rather than just one but by default its still just one.
So I edited it for my domain and keystore password and appending a line at the bottom to restart openfire and popped it into /etc/cron.monthly/ and it works perfectly! Thanks!
Jetty 9.3.13 and 9.4 have now a nice feature to dynamically reload SSL certificates without a restart. I hope Openfire will be ready to use this feature when switching to 9.3.x branch.
Just updated to Openfire 4.1.1 and the issue has indeed been resolved. I can even paste contents of privkey.pem and fullchain.pem into the webUI to update certs.
what did you put for “Pass Phrase used for creating Private Key”? Also, did you include the ----BEGIN PRIVATE KEY----- parts? Currently having difficulty getting letsencrypt stuff to take…
I’m a dummy, systemctl restart openfire fixed the issue now if only letsencrypt were built into openfire…
And did it actually start using the new certificates without a restart? (I’d check with
openssl -connect youropenfire:5222 -starttls xmpp -showcerts or similar)
i wanted to check out your script but it won’t download / display for me? any ideas or thoughts?
Here is the script again:
importopenfirecert.sh.txt (622 Bytes)
Thank you. I’ve reviewed your script;
Using openfire v4.1.3, i simply obtained my cert via webroot and nginx (certonly) and in openfire’s interface, i added to my trust store the cert.pem and privkey and it worked fine. there was no need for passphrases or the chain files or what have you.
is the password spec’d in your script that of the store itself and not that of the privkey? Thanks.
Yes, the password is the default password of the keystore and openfire knows the default password.
If you change this keystore password you have to tell openfire about it:
Where can I generate these keys?