Hipchat Server SSL Installation and Troubleshooting Guide


アトラシアン コミュニティをご利用ください。


プラットフォームについて: サーバーと Data Center のみ。この記事は、サーバーおよび Data Center プラットフォームのアトラシアン製品にのみ適用されます。

This guide is intended for use with Hipchat Server and explains SSL common configuration issues and problems. Most SSL certificate issues for Hipchat Server are caused by:

  • Root CA certificate included in the certificate chain (which is self signed most of the time).
  • Wrong or missing intermediate certificates in the certificate chain.
  • Self-signed certificate(s) located in certificate chain.
  • Badly formed .PEM files.


To check your installed SSL certificate for errors, run this OpenSSL command from the Hipchat Server console:

echo | openssl s_client -showcerts -connect $(hostname):443 -CApath /etc/ssl/ && echo | openssl s_client -connect $(hostname):443 2>/dev/null | openssl x509 -noout -dates -text

This command checks the SSL certificate and chain(s) installed on Hipchat Server, much like a client would request SSL information to start a secure communication.

It details the public certificate chain and any errors that may cause problems. You can run this command either on the server's terminal / SSH console itself or externally:

  • Internal: Use the command provided above
  • Externally: Change the $(hostname) section to the hostname and domain of the server that you are running the check on. For example, hipchat.example.com

When using the comprehensive OpenSSL check, a correctly installed SSL certificate looks like this for example:

HipChat SSL Example
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
verify return:1
depth=0 C = US, ST = CA, L = San Francisco, O = "Example Inc.", CN = *.example.com
verify return:1
Certificate chain
 0 s:/C=US/ST=CA/L=San Francisco/O=Example, Inc./CN=*.example.com
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
Server certificate
subject=/C=US/ST=CA/L=San Francisco/O=Example, Inc./CN=*.example.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
No client certificate CA names sent
SSL handshake has read 3277 bytes and written 421 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 9DB8577FB02B4CAD515ECE59E22194DC8F1D5BD7F19D6A016B15A445A2F2919F
    Master-Key: AAFA57013D6A42D45F6D36F36552887464832281FB409003DCCAE94A1235E46CCBA390827E10D41CBDA38A11C4C9BE42
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - b3 e6 08 37 ae f5 fa 66-e4 ac c6 a9 0d 97 d2 b8   ...7...f........
    0010 - 22 63 24 40 7b ea 1d 1f-9c ea cd 02 a6 dc 2f 22   "c$@{........./"
    0020 - 91 8c 9d 55 98 57 af 14-7b 61 60 93 d1 8c 44 14   ...U.W..{a`...D.
    0030 - 6f e1 9a e2 14 b0 d7 af-76 ba ad 70 d3 78 66 96   o.......v..p.xf.
    0040 - af 9d e2 c4 7d 8e 4f df-a1 88 48 38 7e 28 ca d2   ....}.O...H8~(..
    0050 - aa 37 61 1b 69 cf a0 ea-5e e1 0e 63 2d 79 ce a2   .7a.i...^..c-y..
    0060 - 9f d2 ea f6 8e bf b4 fe-60 15 9a aa 03 7e 4b 7d   ........`....~K}
    0070 - 87 55 92 27 60 b0 1d e9-fa ab fe 32 25 82 e8 be   .U.'`......2%...
    0080 - 6d 5a e4 db 60 c7 ae 9d-67 c3 96 b8 94 83 28 9c   mZ..`...g.....(.
    0090 - 8d a0 47 40 a0 88 12 ab-37 46 bf 70 4d 05 d1 0e   ..G@....7F.pM...
    00a0 - aa 76 e8 da ad 0c b1 61-56 c9 12 d2 0b 91 d7 11   .v.....aV.......

    Start Time: 1510550546
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
notBefore=Aug 31 00:00:00 2016 GMT
notAfter=Sep  5 12:00:00 2018 GMT
        Version: 3 (0x2)
        Serial Number:
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA
            Not Before: Aug 31 00:00:00 2016 GMT
            Not After : Sep  5 12:00:00 2018 GMT
        Subject: C=US, ST=CA, L=San Francisco, O=Example, Inc., CN=*.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:

            X509v3 Subject Key Identifier:
            X509v3 Subject Alternative Name:
                DNS:*.example.com, DNS:example.com
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points:

                Full Name:

                Full Name:

            X509v3 Certificate Policies:
                Policy: 2.16.840.1.114412.1.1
                  CPS: https://www.digicert.com/CPS

            Authority Information Access:
                OCSP - URI:http://ocsp.digicert.com
                CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt

            X509v3 Basic Constraints: critical
    Signature Algorithm: sha256WithRSAEncryption

In this example, there are two certificates listed in the certificate chain. Usually, certificate 0 is the primary certificate and can be easily identified by the CN which should list the fully qualified domain name (FQDN). Certificate 1 is the intermediate certificate. 

Root Cert

If a certificate is installed that has the same subject and issuer line (also called a self-signed certificate), then, more than likely, that is a root certificate and needs to be removed from the chain (because the root certificates are normally housed in the client trust-store).

Common OpenSSL Error Codes

エラー コード 説明
verify error:num=27:certificate not trustedThis normally comes together with the errors num=21 where the server doesn't have the intermediate certificates needed to verify the SSL certificate.
verify error:num=26:unsupported certificate purposeThis means that the certificate being installed isn't a Server certificate and cannot be used for Server SSL handshaking.
verify error:num=21:unable to verify the first certificateThis can mean that either some or all the intermediate certificates required to establish the chain of trust between the primary certificate (the one you buy from a CA vendor) and the Root certificate (housed and served by the client) is missing. See below for troubleshooting steps.

verify error:num=20:unable to get local issuer certificate

The -CApath is not specified or not found. Verify that the -CApath is pointed to the local certificate store. For Hipchat Server that is /etc/ssl/ but may be different depending on what console/terminal you are using to query the Server. See below for troubleshooting steps.
Verify return code=19:self signed certificate in certificate chainOne or more of the certificates in the chain has a self-signed certificate. Root CA certificates are almost always self-signed. See below for troubleshooting steps.
Verify return code=18:self signed certificate The default self signed certificate that comes together during the installation of Hipchat Server / generated through hipchat certificates --selfsign command is still being used in the instance. See below for troubleshooting steps.

Error - Unsupported Certificate Purpose

When running an OpenSSL check against a CSR or a CRT file, you may see this error:

verify error:num=26:unsupported certificate purpose


  1. Run the following command inside Hipchat Server command line interface:

    Check against installed SSL certificate
    openssl s_client -showcerts -connect localhost:443 </dev/null 2>/dev/null|openssl x509 -text |grep v "$(grep -E -A1 "Key Usage")"

    or run a check against your .crt file:

    Check against a .crt file
    openssl x509 -text -noout -in <filename for crt>.crt
  2. In the output under X509v3 Extended Key Usage should be the following line: TLS Web Server Authentication
  3. If this line is missing, then the certificate isn't specifically setup for Server handshaking. You will need to reach out to your CA and ask them to generate a Server certificate.
  4. If the command returns grep: : No such file or directory then you do not have the certificate installed (are you using a self-signed certificate?)


This error specifically states that the intended purpose of the certificate installed does not include the role to act as a Server certificate thus cannot be used for handshaking when a client attempts to connect.

Error - Unable to verify the first certificate

When running OpenSSL check, an installed SSL cert from trusted CA vendor shows the following error:

verify error:num=21:unable to verify the first certificate


  1. Verify that you have an intermediate certificate installed.
  2. If you have an intermediate certificate installed, it's possible that you may need more than one to establish trust. This is common with vendors such as Entrust. Check with your vendor regarding how many intermediate certificates you need.
  3. You can use the GeoCerts SSL Checker tool to visually see your chain and check if any intermediate certs are missing.
  4. If you've recently installed a chain with an intermediate certificate, first snapshot or back up your instance. (This will disconnect any user that's currently connected to the service.) Then restart the services (HipChat service -restart) or rebooting the Server (sudo reboot). 


The primary certificate (the one you purchase from a vendor) cannot establish the chain of trust between itself and the Root certificate stored locally. Usually installing the intermediate certificates fixes this.

Error - Unable to get local issuer certificate

When running OpenSSL check, an installed SSL cert from trusted CA vendor shows:

verify error:num=20:unable to get local issuer certificate


  1. Verify that you are using the -CApath argument when running the OpenSSL check.
  2. Verify that the path to the local certificate storage is correct (Hipchat Server local certificate trust-store is /etc/ssl).


This error code is thrown when a local certificate path is not found during the OpenSSL check is used. This error is specific to the OpenSSL check. Generally, it can be ignored and doesn't affect the trust of a certificate chain.

Error - Self-signed certificate in certificate chain

When running OpenSSL check, an installed SSL cert from trusted CA vendor shows:

Verify return code=19:self signed certificate in certificate chain


  1. Install a trusted CA signed primary SSL certificate and an intermediate certificate.
  2. Verify that the Root CA is not included in the certificate chain (as this is almost always self-signed).
  3. If you've removed the Root CA cert, first snapshot or back up your instance. (This will disconnect any user that's currently connected to the service.) Then restart the services (HipChat service -restart) or rebooting the Server (sudo reboot). 


This error is thrown whenever there is a self-signed certificate in the chain. When Hipchat Server is booted for the first time, it generates a self-signed certificate for testing purposes. We highly recommend replacing this certificate with a certificate chain from a trusted vendor.

Error - The certificate and key do not match

When uploading your SSL private key and certificate through the Hipchat Server administrative interface or command-line interface, the following error occurs:

Unable to update: The certificate and key do not match


Use the following commands to generate an MD5 sum for the private key, certificate signing request (CSR), and certificate files:

openssl rsa -noout -modulus -in domain.key | openssl md5
openssl x509 -noout -modulus -in domain.crt | openssl md5
openssl req -noout -modulus -in domain.csr | openssl md5

Verify that the output string from each command is identical to verify that the files are matching. If the outputs are identical but problem persists, try to re-install the SSL certificate you get from CA as cleanly as possible. Start with reconfiguring the server to use self-signed certificate and then re-import the trusted SSL certificate into the server again:

hipchat certificates --selfsign
cat hipchat-example-com.crt > new.pem
cat hipchat-example-com.key >> new.pem
hipchat certificates --import new.pem

If problem persists even after cleanly importing the certificate, there could be a problem with the certificate that the CA generated. Reach out to the CA to re-issue the SSL certificate followed by a re-installation of the new certificate on the server. On a side note, the wrong order of your SSL certificate could also produced similar error. Double check the SSL certificate format following the recommended format here: Creating or Obtaining an SSL Key and Certificate


The private key and certificate being uploaded do not match and are incompatible with each other. It will be necessary to re-form the private key, CSR, and/or certificate in such a way that they do match, at which point they can be uploaded to the Hipchat Server.

Error - self signed certificate

Consider purchasing a trusted CA signed SSL certificate to tackle this issue permanently.

SSL Certificate Chain Ideal Setup

As listed in the Creating or Obtaining an SSL Key and Certificate, when installing the SSL certificate chain in Hipchat Server, please make sure that your .pem file includes the RSA private key, the primary certificate and an intermediate certificate. This gives the certificate chain the best chance of minimizing problems with trust in Hipchat Server.

ECC Certificates

At this time, Hipchat Server is not compatible with ECC (Elliptic Curve Cryptography) or ECDH (Elliptic Curve Diffie–Hellman) generated SSL certificates.

Trust Issues

The chain of trust extends from the root certificate (also called the anchor certificate) to the intermediate certificate then to the primary certificate. If there are any errors or issues with trust throughout the chain, the following issues may happen:

Self-Signed Certificates

Hipchat Server generates a self-signed certificate and private key when it is first deployed. This certificate is meant for testing purposes and is not recommended that you use it in a production environment.

To ensure that the functionalities of Hipchat Server are not affected in any way, we always recommend you to obtain a trusted CA signed full certificate chain applied on your instance.

Internally Signed SSL Certificates

If your group is using an SSL certificate signed by an internal CA (opposed to a vendor like DigiCert), the internal CA will need to provide the corresponding RSA private key, primary, and intermediate certs to install in Hipchat Server. Once the SSL chain is installed in Hipchat Server, install the root certificate into the trust-store of the OS running the Hipchat client. This adds the certificate as 'trusted' which is needed when connecting to the Hipchat Server certificate chain. If the root certificate is not installed in the OS running the Hipchat client, then the trust will not be established and you may have problems connecting the client.

最終更新日 2018 年 11 月 8 日


Powered by Confluence and Scroll Viewport.