Users won't be able to log in to your site at all via the Confluence Server mobile app if you use a self-signed certificate. This usually will only occur the first time they access the site. In general, you might use a self-signed certificate on a test environment and on internal corporate networks (intranets).īecause the certificate is not signed by a certificate authority (CA), users may receive a message that the site is not trusted and may have to perform several steps to accept the certificate before they can access the site. Self-signed certificates are useful if you require encryption but don't need to verify the identity of the requesting website. Option 1: Create a self-signed certificate You can't use the app with a self-signed certificate, or one from an untrusted or private CA.
If your team plans to use the Confluence Server mobile app, you'll need a certificate issued by a trusted Certificate Authority. You can create your own self-signed certificate, or acquire one from a trusted Certificate Authority. If you already have a certificate, skip to step 2. You'll need a valid certificate before you can enable HTTPS. We recommend you enable HTTPS on your site. You’d rarely need to do what I’ve shown above, but in case you have to, I hope the hints above were useful.Running Confluence without HTTPS enabled may leave your site exposed to vulnerabilities, such as man-in-the-middle or DNS rebinding attacks. Of course, if you have to do very specific or odd stuff, you’ll have to revert to command line, but for most operations the UI is sufficient (unless you have to automate it, in which case, obviously, use the CLI). It is a great tool that makes working with keys and keystores easy and predictable, as opposed to command-line tools like keytool and openssl, which I’m sure nobody is able to use without googling every single command. You’ve noticed my preference for keytool-explorer. This is straightforward through the keystore-explorer UI, and much less easy through the command line. for timestamping, the extension file looks like this:Īfter that “simply” create a new keystore and import the private key and the newly generated certificate. The extfile.cnf is optional and is used if you want to specify extensions. X509 -req -days 3650 -in req.csr -signkey private.key -sha256 -extfile extfile.cnf -out result.crt And you can’t remove the certificate and generate a new one. If you try to sign the request with your existing keystore keypair, the current certificate is used as the root of the chain (and you don’t want that). The last two steps seem to be not straightforward with keytool or keystore exporer. Import the certificate in the store to replace the old (expired) one.Sign the request with the private key (i.e.Make a certificate signing request ( with keytool or through the keystore-explorer UI).Export the private key ( with keytool & openssl or through the keystore-explorer UI, which is much simpler).In order to reuse the private key to have a new, longer certificate, you need to do the following: Even with my favourite tool, keystore explorer, it’s not immediately possible. This sounds like something that should be easy to do, but it turns it it isn’t that easy with keytool. However, you can have a new certificate with the same private key and a longer period. This is useful mostly for testing and internal systems, but still worth mentioning.Įxtending certificates is generally not possible – once they expire, they’re done. And after the certificate in initially generated jks file expires, you have few options – either generate an entirely new keypair, or somehow “extend” the existing certificate. Sometimes you don’t have a PKI in place but you still need a key and a corresponding certificate to sign stuff (outside of the TLS context).
0 kommentar(er)
