No announcement yet.

MySQL SSL and Docker

  • Filter
  • Time
  • Show
Clear All
new posts

  • MySQL SSL and Docker

    We are attempting in enforce SSL connections between a Mirth container (the image is based off the official docker source code here, and an Azure MySQL database. However, when we enable SSL on the MySQL server and force SSL connections via the JDBC connection url in, the Mirth fails to connect. If we disable SSL on the MySQL server, Mirth connects just fine.

    Microsoft provides some documentation about enabling SSL connections here

    They provide a .pem cert that we assume needs to be imported somewhere in the container that is running Mirth. We've been trying to follow instructions ( for importing a cert into the keystore that's in /appdata, and we've tried using an example connection url (, but we have still been unsuccessful.

    We are not confident that we are importing the .pem cert properly, and the example connection url found in the thread mentioned earlier is confusing. Can we get some help?

  • #2
    The mircosoft doc says that's a CA Cert, so it needs to go into your truststore, not your keystore (this is a public key that you need to trust.)

    Mirth uses your system truststore by default, and is in different places depending on several factors including OS and JRE.

    Alternatively, according to the mysql doc you linked, it looks like you can create a new truststore specifically for this connection, and specify the location in your jdbc url by adding properties


    • #3
      Actually, I think there's a typo in that document. The properties should be trustCertificateKeyStoreUrl and trustCertificateKeyStorePassword. You may also want to use trustCertificateKeyStoreType and set the type to PKCS12 (also when you create the truststore use that type.)


      • #4

        Here's how to create a pkcs12 keystore/truststore from the .pem file using openssl.

        openssl pkcs12 -export -in mykeycertificate.pem.txt -out mykeystore.pkcs12 -name myAlias -noiter -nomaciter


        • #5
          For context, we are running the containers on Linux nodes, and the Dockerfile we are using is based off of


          • #6
            Sorry, you said that in your original post and I glazed right over that. In this case, I would probably go with creating the separate truststore, because it will be easier to add that file, either through a custom Dockerfile or using a docker volume, than to try to update the system truststore stored in the container.


            • #7
              We are attempting to go the custom Dockerfile route.