[Other doc versions]
This page is intended for administrators setting up Stash for a small team. It describes how to enable HTTPS (HTTP over SSL) access for Tomcat, the webserver distributed with Stash, using a self-signed certificate. You should consider doing this, and making secure access mandatory, if Stash will be internet-facing and usernames, passwords and other proprietary data may be at risk.
If you are setting up a production instance you should consider using a CA certificate, briefly described below.
There are other network topology options for running Stash, including running Stash behind a reverse proxy. For an overview of some common options, see Proxying and securing Stash.
When Stash is set up following the instructions on this page, access to Stash is direct, and all communication between the user's browser and Stash will be secured using SSL.
Please note that Atlassian Support will refer SSL-related support to the issuing authority for the certificate. The documentation on this page is for reference only.
Self-signed certificates are useful where you require encryption but do not need to verify the website identity. They are commonly used for testing and on internal corporate networks (intranets).
Users may receive a warning that the site is untrusted and have to "accept" the certificate before they can access the site. This usually will only occur the first time they access the site.
The following approach to creating a certificate uses Java's keytool. Other tools for generating certificates are available.
To generate a self-signed certificate:
Log in with the user account that Stash will run under, and run the following command:
"%JAVA_HOME%\bin\keytool" -genkey -alias tomcat -keyalg RSA -sigalg SHA256withRSA
|Linux, Mac OS X|
$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA -sigalg SHA256withRSA
This will create (if it doesn't already exist) a new
.keystore file located in the home directory of the user you used to run the keytool command.
If you used the Stash installer to install Stash as a service on your system, the installer will have created a user account called
atlstash. This account is locked (it cannot be used to log in to the system) and doesn't have a home directory. In this case you need to specify a location for the
.keystore file using the
keystore parameter like this:
"%JAVA_HOME%\bin\keytool" -genkey -alias tomcat -keyalg RSA -sigalg SHA256withRSA -keystore /path/to/keystore/stash.jks
|Linux, Mac OS X|
$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA -sigalg SHA256withRSA -keystore /path/to/keystore/stash.jks
Note the following:
What is your first and last name?
conf/server.xmlby adding the following attribute to the
To configure HTTPS in Tomcat:
conf/server.xml and, at the bottom, before the
</Service> tag, add this section (or uncomment this if it already exists):
This enables SSL access on port 8443 (the default for HTTPS is 443, but 8443 is used here instead of 443 to avoid conflicts).
If you created the keystore somewhere else on the filesystem, add the
keystoreFile attribute to the connector tag as well:
Comment out the existing Connector directive for port 7990 in
conf/server.xml, so as to disable HTTP access, if you want all access to Stash to make use of HTTPS. That is, comment out this directive:
If Stash will run as the user who ran the
keytool --genkey command, you do not need to export the certificate.
You may need to export the self-signed certificate, so that you can import it into a different keystore, if Stash will not be run as the user executing
keytool --genkey. You can do so with the following command:
"%JAVA_HOME%\bin\keytool" -export -alias tomcat -file file.cer
|Linux, Mac OS X|
$JAVA_HOME/bin/keytool -export -alias tomcat -file file.cer
If you generate the certificate as one user and run Stash as another, you'll need to do the certificate export as the generating user and the import as the target user.
Digital certificates that are issued by trusted 3rd party CAs (Certification Authorities) provide verification that your website does indeed represent your company.
First, you will generate a local certificate and create a 'certificate signing request' (CSR) based on that certificate. You then submit the CSR to your chosen certificate authority. The CA will use that CSR to generate a certificate for you.
keytoolutility to generate a local certificate, as described in the section above.
keytool utility to generate a CSR, replacing the text
<MY_KEYSTORE_FILENAME> with the path to and file name of the
.keystore file generated for your local certificate:
"%JAVA_HOME%\bin\keytool" -certreq -keyalg RSA -alias tomcat -file certreq.csr -keystore <MY_KEYSTORE_FILENAME>
|Linux, Mac OS X|
$JAVA_HOME/bin/keytool -certreq -keyalg RSA -alias tomcat -file certreq.csr -keystore <MY_KEYSTORE_FILENAME>
certreq.csrto your chosen certificate authority. Refer to the documentation on the CA's website to find out how to do this.
Import the new certificate into your local keystore. Assuming your certificate is called "file.cer" whether obtained from a CA or self-generated, the following command will add the certificate to the keystore:
"%JAVA_HOME%\bin\keytool" -import -alias tomcat -file file.cer
|Linux, Mac OS X|
$JAVA_HOME/bin/keytool -import -alias tomcat -file file.cer
前述の説明に従って keytool で作成した自己署名証明書、または CA 証明書を使用する場合の、トラブルシューティングのヒントをいくつか紹介します。
When you enter "
logs/catalina.out log file. Here are some possible errors with explanations:
Some people have reported errors when uploading attachments over SSL using IE. This is due to an IE bug, and can be fixed in Apache by setting:
Google has plenty more on this.
java.io.FileNotFoundException: /home/user/.keystore (No such file or directory)
This indicates that Tomcat cannot find the keystore. The keytool utility creates the keystore as a file called
.keystore in the current user's home directory. For Unix and Linux the home directory is likely to be
/home/<username>. For Windows it is likely to be
Make sure you are running Stash as the same user who created the keystore. If this is not the case, or if you are running Stash on Windows as a service, you will need to specify where the keystore file is in
conf/server.xml. Add the following attribute to the connector tag you uncommented:
java.io.IOException: Keystore was tampered with, or password was incorrect
You used a different password than "changeit". You must either use "changeit" for both the keystore password and for the key password for Tomcat, or if you want to use a different password, you must specify it using the
keystorePass attribute of the Connector tag, as described above.
java.io.IOException: Cannot recover key
javax.net.ssl.SSLException：有効化されている SSL 暗号化スイートと一致する、利用可能な証明書がありません。
If the Keystore has more than one certificate, Tomcat will use the first returned unless otherwise specified in the SSL Connector in
keyAlias attribute to the Connector tag you uncommented, with the relevant alias, for example:
APR では異なる SSL エンジンが使用されており、次のような例外処理情報がログに記録されることがあります。
SEVERE: Failed to initialize connector [Connector[HTTP/1.1-8443]] LifecycleException: Protocol handler initialization failed: java.lang.Exception: No Certificate file specified or invalid file format
これは APR コネクターが OpenSSL を使用しており、キーストアの使用方法が異なることが原因です。この問題の解決策は 2 通りあります :
Edit the server.xml so that the SSL Connector tag you just uncommented specifies the Http11Protocol instead of the APR protocol:
This is only possible if you have PEM encoded certificates and private keys. If you have used OpenSSL to generate your key, then you will have these PEM encoded files - in all other cases contact your certificate provider for assistance.
To enable client authentication in Tomcat, ensure that the value of the
clientAuth attribute in your
Connector element of your Tomcat's
server.xml file is
For more information about
Connector element parameters, please refer to the 'SSL Support' section of the Tomcat 6.0 documentation.
If the certificate from the CA is in PKSC12 format, add the
keystoreType attribute to the SSL Connector in
キーストアでエンティティ / ドメイン証明書よりも手前にルート証明書と中間証明書がインポートされていない場合、次のエラーが表示されます。
Most likely, the CA sent a compressed file containing several certificates. The import order matters so you must import the root certificate first, followed by one or many intermediate certificates, followed lastly by the entity/domain certificate. There are many resources online that provide guidance for certificate installation for Tomcat (Java-based) web servers using keytool.
Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.