Many years ago when I started adding certificates management to Openfire I couldn’t stop thinking how complex the certificate management topic was. Moreover, I thought that the lack of information regarding certificates management was on purpose as a way to keep them “secure”.
Even though I do not consider myself an expert in security and certificates in particular, I think I finally understood the different ways certificates can be created, signed by Certificate Authorities (CA) and finally be imported into your application. Basically there are two ways for this to be achieved and fortunately the XMPP Federation through its CA services supports both of them.
Create your certificate and ask a CA to sign it
In this case you will create a certificate from the admin console of Openfire and then ask Openfire to create a Certificate Signing Request (CSR) that is sent to the CA. The Certificate Authorities (CA) usually has a web site that you can use to paste the CSR. If you are using the XMPP Federation services, choose the menu option Server Certificate (Without CSR generation). After the CA verified the certificate data and the data of the certificate issuer you will get a signed certificate that you will need to import into Openfire from the admin console.
The CA creates a certificate for you and signs it
In this case almost the entire process happens in the CA web site and administrators will need to import the signed certificated into Openfire. If you are using the XMPP Federation services, choose the menu option Server Certificate (With CSR generation) and then provide a pass phrase to create the certificate and its private key. After the data was validated you will receive a signed certificate. The last step to import the new certificate into Openfire is to paste the pass phrase, private key and signed certificate in the import certificate page in Openfire and voila.
As of Openfire 3.4.2 you will be able to choose the certificate management option that best fits you and follow the entire process from the admin console. You will be able to say bye bye to the cumbersome command line tools. If you are using Openfire 3.4.1 or older then only the first option is supported.
I found portecle (http://portecle.sourceforge.net/) quite nice to explore Java keystores and manage certs, but unfortunatly it is no longer maintained.
Related to Gato’s work is the concept of Certificate Revocation. Say the CA issued a certificate by accident, or perhaps it was compromised. We obviously don’t to trust that certificate anymore. There are two common ways of handling this problem. First, Certificate Revocation Lists (CRL’s) are generated by the CA, and contain a list of all the revoked certificates. The other (slightly less) common method is Online Certificate Status Protocol (OCSP). Since CRL’s are static files you download, they may not always be current, and OCSP is an online service that allows you to be more up to date. The downside is you have to have connectivity to an OCSP server for it to work (a point of failure, for some networks). Ive been working on getting this support into Openfire, and hope to soon provide support for CRL’s, with the OCSP support not far behind.
If the server hostname does not match the XMPP domain (because you use a SRV record), should the RSA certificate be for the server hostname and the DSA certificate be for the XMPP domain, and does the server software have any support for this? (I’m still a little unclear on how the certificates are used.)
ghudson: I think the problem is Openfire uses the same cert for the xmpp service and the admin console https. If you use srv records, you are likely reaching the admin console via the host name, not the service name, and thus a mismatch.
Jay is correct, Openfire is using the same keystore, that keeps generated XMPP certificates, for XMPP clients and also for the HTTP browsers. I wonder if besides storing the XMPP certificates in the keystore and adding standard certificates for HTTP browsers in the same keystore would solve the problem you are seeing. You can use the keytool command line tool to add none XMPP certificates to the keystore file.
Good catch. You might want to contact the CA and ask them to add that new feature and in the meanwhile use another CA to create both DSA and RSA certs. BTW, which clients do only accept DSA certs and not RSA? or vice versa?
Hey Peter, Openfire does not require a DSA and a RSA key to offer TLS. However, the UI in the admin console will alert admins when one of those keys are missing but it won’t prevent anything from functioning.
The reason why Openfire expects both keys is historical. I think that a long time ago the server used to offer DSA keys only and one client was having trouble using TLS and we figured out that it was because it needed an RSA key. We then added an RSA key but we never verified if all clients were happy with an RSA key so we could deprecate the warning message in the admin console when no DSA key was installed. In summary, do you know if having only an RSA key will make all clients happy?
Hmm. As far as I can see (no, I an not a member of the security mafia), it should be fine for a server deployment to offer either a DSA key or an RSA key. IMHO the connecting client should not limit the acceptable algorithms to one of DSA or RSA, but instead should accept keys generated with the DSA algorithm or the RSA algorithm as equally valid. It seems confusing if the server deployment offers both a DSA key and an RSA key since (as far as I can see) that should not be necessary – it should be fine to offer one or the other, but not both. Now, it is true that the RSA algorithm is more widely deployed (or was the last time I did some research on this) and is the “de facto” standard for key-generation algorithms, so I suppose it is possible that some (older?) clients may not accept keys generated with the DSA algorithm. But that seems like a client bug and not something that the server codebase should try to fix by allowing two different certificates. However someone who knows more about this than I do may be able to correct me…
Just to clarify: by default Startcom will create the certificate using the RSA algorithm, but you can specifically request use of the DSA algorithm in your CSR.
My understanding is that DSA-based authentication offers better security as compared to RSA, but costs more in terms of CPU cycles when authenticating. For this reason a server might want to offer both; for example, an enterprise might deploy DSA keys on traditional desktop/laptop clients and RSA keys on mobile devices.
I think it is a bad idea to offer two certificates for the same XMPP service, since the certificate identifies the service. It seems fine to offer a certificate that is generated using the DSA algorithm or a certificate that is generated using the RSA algorithm, but not both.
I’m trying to import a certificate using the ‘Import Signed Certificate’ page in Openfire 3.4.2 but need to import the root certificate of the CA signing my certificate into the truststore first. When I use keytool to do this I am prompted to enter a password (I assume for the truststore). Not knowing the password (if any) I just pressed enter but get a NullPointerException. I’m using the following command:
I chose to update my issuer information in the admin console, and entered the appropriate values. Now the admin console shows me that both of my certificates are self-signed, and does not offer me CSRs or any option to generate them. How do I get from that state to CSRs I can submit?
