YouTrack with built-in TLS, Docker, and Slack

Avatar
Pawel Staniszewski
Created

Hello,

We launched the latest version of YouTrack with built-in TLS (we had huge problems with Nginx reverese-proxy).

Unfortunately, after the update, Slack notifications are not working.

The command below has been working without any changes for 5 years, so I suspect that Docker + built-in TLS caused the problems

const connection = new http.Connection("https://hooks.slack.com/services/...", null, 1000);
const response = connection.postSync("", null, JSON.stringify(payload));

Log Workflow:

Certificate for <hooks.slack.com> doesn't match any of the subject alternative names: [*.company.com, company.com]

Additionally (I'm posting this in the same thread because it seems to be related) selecting the "Integrate with Slack" option in the admin panel also generates an error:

javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

That's how we started the container:

sudo docker run -it --name yt \
-v /home/youtrack/data:/opt/youtrack/data \
-v /home/youtrack/conf:/opt/youtrack/conf \
-v /home/youtrack/logs:/opt/youtrack/logs \
-v /home/youtrack/backups:/opt/youtrack/backups \
-p 8080:8080 \
-p 8443:8443 \
jetbrains/youtrack:2025.1.64291

Can I ask for some advice?

Votes

1

Share

3 comments
Avatar
Sergey Merzlov
Created
Official comment

Hi Pawel,  

I'm Sergey from the YouTrack team.  

I can confirm that the 8443 port in YouTrack Docker containers doesn’t have any special meaning. Outbound traffic from the container typically traverses the host's network stack. This means that when you execute `curl` inside the container, the traffic doesn’t go directly to Slack but passes through your host's network configuration.  

It’s likely that your host, firewall, or proxy intercepts TLS traffic on port 8443 and overrides the certificate. Switching to port 443 seems to resolve this issue, which aligns with this theory. If you prefer to use port 8443, I recommend having your IT team review your network configuration to ensure it’s not intercepting or restricting traffic on that port. YouTrack itself doesn’t impose any limitations or traffic interception rules.  

Let me know if you need further clarification!

Avatar
Pawel Staniszewski
Created

I'll add one more detail. We can't execute a query (i.e. with curl) from the container level either.

We tested this on a clean server and a clean YouTrack installation (without restoring the database).

The same curl as below works without a problem on a server, but not inside YouTrack container:

bash-4.2# curl -v -X POST -H 'Content-type: application/json' --data '{"text":"Hello, World!"}' https://hooks.slack.com/services/SECRET/SECRET/SECRET
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 3.68.170.153:443...
* Connected to hooks.slack.com (3.68.170.153) port 443
* ALPN: curl offers h2,http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

If we ignore the certificate issues, this query fails too --- and tries to fetch our corporate certificate (which we used to configure YouTrack TLS) instead of the site's certificate (in this case Slack)

bash-4.2# curl -k -v -X POST -H 'Content-type: application/json' --data '{"text":"Hello, World!"}' https://hooks.slack.com/services/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
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 3.68.175.98:443...
* Connected to hooks.slack.com (3.68.175.98) port 443
* ALPN: curl offers h2,http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.our-company.com
0
Avatar
Pawel Staniszewski
Created

Starting the container with the 443 -> 443 mapping fixed the problem.

docker run \
-it \
--name yt \
-v /home/youtrack/data:/opt/youtrack/data \
-v /home/youtrack/conf:/opt/youtrack/conf \
-v /home/youtrack/logs:/opt/youtrack/logs \
-v /home/youtrack/backups:/opt/youtrack/backups \
-p 8080:8080 \
-p 443:443 \
jetbrains/youtrack:2025.1.64291

It seems that port 8443 inside the container has some special meaning.

0

Please sign in to leave a comment.