Oracle

Mirth® Connect by NextGen Healthcare User Guide

PostgreSQL

The simplest way to enable SSL/TLS traffic is to add "ssl=true" to your JDBC URL. For example: jdbc:postgresql://localhost:5432/mirthdb?ssl=true There is also an "sslmode" property you can use for more granular options: jdbc:postgresql://localhost:5432/mirthdb?sslmode=verify-full And many other options as well. Consult these online documentation pages for more information: https://www.postgresql.org/docs/current/ssl-tcp.html https://jdbc.postgresql.org/documentation/ssl https://jdbc.postgresql.org/documentation/head/connect.html#ssl Parent topic: Connect to Database using SSL/TLS

Mirth® Connect by NextGen Healthcare User Guide

SQL Server

Using the built-in jTDS JDBC driver, you can enable SSL/TLS by using the "ssl" option: jdbc:jtds:sqlserver://localhost:1433/mirthdb?ssl=authenticate The above option will require SSL/TLS traffic and require that the server certificate is trusted. If you want to accept self-signed certs, you can reduce the security level and use "ssl=require" instead. Using the Microsoft JDBC driver, you can enable SSL/TLS by using the "encrypt" option: jdbc:sqlserver://localhost:1433;databaseName=mirthdb;encrypt=true;trustServerCertificate=true Consult these online documentation pages for more information: http://jtds.sourceforge.net/faq.html https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/enable-encrypted-connections-to-the-database-engine https://docs.microsoft.com/en-us/sql/connect/jdbc/using-ssl-encryption Parent topic: Connect to Database using SSL/TLS

Mirth® Connect by NextGen Healthcare User Guide

MySQL

By default, the MySQL Connector/J JDBC driver will automatically connect via SSL/TLS if the server supports it. To force encrypted traffic at all times, use the sslMode parameter: jdbc:mysql://localhost:3306/mirthdb?sslMode=VERIFY_IDENTITY The above mode makes sure that SSL/TLS is always used, the server cert is trusted, and hostname verification is also performed. For a more lenient and less secure connection (but still using SSL/TLS), you can also use the VERIFY_CA option which skips the hostname verification, or the REQUIRED option which doesn't require the server cert to be trusted and will work for self-signed certs. Consult these online documentation pages for more information: https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-configuration-properties.html Parent topic: Connect to Database using SSL/TLS

Mirth® Connect by NextGen Healthcare User Guide

Importing the Database Server Certificate

If the certificate your database is using is self-signed or not signed by a common trusted Certificate Authority (CA), then you will likely need to import that certificate into your default Java truststore in order to connect to your database using SSL/TLS. Your default Java truststore is typically the "cacerts" JKS file that usually resides inside your Java installation folder under "jre/lib/security", and the default password is "changeit". You can also override the default truststore by supplying the "-Djavax.net.ssl.trustStore" JVM option into the mcserver.vmoptions or mcservice.vmoptions files. Using keytool: keytool -importcert -keystore /path/to/javahome/jre/lib/security/cacerts -storepass changeit - alias myalias - file /path/to/cert/server .crt -noprompt Make sure to change the paths and alias above as needed. Depending on your permissions you may need to perform this as sudo/Administrator to edit the Java cacerts truststore. You can also use a GUI tool like Portecle to import

Mirth® Connect by NextGen Healthcare User Guide

Connect to Database using SSL/TLS

By default, Mirth® Connect is configured to connect to an embedded Apache Derby database for quick deployment, development, and testing. When using Mirth® Connect in production environments, we recommend changing the underlying database to one of the supported servers: PostgreSQL 8.3+ MySQL 5.6+ Oracle 10gR2+ SQL Server 2005+ There is more information on changing the database type here: Changing the Database Type And more information about configurable options in mirth.properties here: mirth.properties File Typically these database connections are not encrypted by default. The instructions to enable SSL/TLS traffic for database connections differ depending on the database and JDBC driver you are using. Here are some instructions for each of the supported backend databases. For more information, consult the manuals for the specific database and JDBC driver you are using. Importing the Database Server Certificate PostgreSQL MySQL Oracle SQL Server Parent topic: Secure Installation and De

Mirth® Connect by NextGen Healthcare User Guide

4.0.0 Upgrade Notes

Database Reader XML Casing In 3.12.0 we updated Apache Commons DBUtils and made some associated changes in our code. As part of that change, the XML created by the Database Reader was using the same case that appeared in the actual SQL query, whereas before 3.12.0 everything was normalized to lowercase. In 4.0.0, we made some more updates in the Connect codebase to, again, normalize the casing to all lowercase. If you are upgrading to 4.0.0 from any version before 3.12.0 there is no change for you and database queries will use the casing they always have. If you are upgrading to 4.0.0 from 3.12.0 and had made changes adding AS clauses in your queries to work around the casing change in 3.12.0 there is no change for you. If you experienced database query errors after upgrading to 3.12.0 due to casing in the query statements, after upgrading to 4.0.0 you should no longer encounter those errors. TLS Protocols and Cipher Suites Default TLS protocols and cipher suites have been updated. Wea

Oracle

Recommendations

PostgreSQL

SQL Server

MySQL

Importing the Database Server Certificate

Connect to Database using SSL/TLS

4.0.0 Upgrade Notes

PostgreSQL

SQL Server

MySQL

Importing the Database Server Certificate

Connect to Database using SSL/TLS

4.0.0 Upgrade Notes