Update Your Amazon RDS SSL/TLS Certificates by February 5, 2020

(Ralf Lukner MD PhD) #1

I received the following message from Amazon (AWS). What does this update involve with respect to OpenEMR Standard Edition?
Thank you,

Important Reminder: Update Your Amazon RDS SSL/TLS Certificates by February 5, 2020 [AWS Account: ZZZZZZZZZZZZ]

Amazon Web Services, Inc.

Dec 11, 2019, 2:46 AM (3 days ago)

to me

We previously sent a communication in early October to update your RDS SSL/TLS certificates by October 31, 2019. We have extended the dates and now request that you act before February 5, 2020 to avoid interruption of your applications that use Secure Sockets Layer (SSL) or Transport Layer Security (TLS) to connect to your RDS and Aurora database instances. Note that this new date is only 4 weeks before the actual Certificate Authority (CA) expiration on March 5, 2020. Because our own deployments, testing, and scanning to validate all RDS instances are ready for the expiry must take place during the final 4 weeks, the February 5th date cannot be further extended.

You are receiving this message because you have an Amazon RDS database instance(s) that requires action in the XXXXXXXX Region, listed at the end of the email.

To protect your communications with RDS database instances, a CA generates time-bound certificates that are checked by your client applications that connect via SSL/TLS to authenticate RDS databases before exchanging information. AWS renews the CA and creates new root certificates every five years to ensure RDS customer connections are properly protected for years to come.

The current CA expires on March 5, 2020, requiring updates to client applications and database instances that have certificates referencing the current CA. Client applications must add new CA certificates (root and intermediate where necessary) to their trust stores, and RDS database instances must separately use new server certificates before this hard expiration date. However, we strongly recommend you complete these changes before February 5, 2020. After February 5, 2020, we will begin scheduling certificate rotations for your RDS database instances prior to the March 5, 2020 deadline. The automatic update(s) will be scheduled within your maintenance window.

Additionally, any new RDS database instances created after January 14, 2020 (previously November 1, 2019) will default to using the new certificates. If your client applications have not been updated to add the new certificates to their trust stores, these applications will fail to connect to any new instances created after this date. If you wish to temporarily modify new instances to use the old certificates, you can do so using the AWS console, the RDS API, and the AWS CLI. Any instances created prior to January 14, 2020 will have the old certificates until you update them to the rds-ca-2019 version.

If your applications connect to RDS database instances using the SSL/TLS protocol, please follow the detailed instructions in the links below. Based on your feedback, we have provided, per database engine, further instructions on 1.) how to determine whether your client applications are connecting to your RDS databases via SSL/TLS and 2.) how to update your client application trust stores to include the new CA certificates.

If your applications do not use SSL/TLS to connect, there are no required actions that you need to take. However, using SSL/TLS is a security best practice so we recommend all customers perform this upgrade so that your applications can start using SSL seamlessly. Before March 5, 2020, RDS will schedule and perform pending maintenance actions which you can view in the RDS console to ensure you have valid certificates after the current certificates expire. The automatic update(s) will be scheduled within your maintenance window.

For RDS: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL-certificate-rotation.html
For Aurora: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.SSL-certificate-rotation.html

We encourage you to test these steps in a development or staging environment before implementing them in your production environments. If not completed, your applications using SSL/TLS will fail to connect to your existing database instances as soon as RDS rotates your certificates on the database side prior to March 5, 2020.

(Ralf Lukner MD PhD) #2
  • Bump *
    Does the AWS version(s) of OpenEmr use Amazon RDS SSL/TLS certificates that need to be updated to avoid interruption in service?

(Stephen Waite) #3

hi @Ralf_Lukner, pretty sure @jesdynf is looking into this

(Asher Densmore-Lynn) #4


I’m pretty sure fix Standard MySQL cert error · openemr/openemr-devops@9ea0a9f · GitHub picks up those changes. If you’re using a version of Standard that predates it and you need to pull in a certificate file manually, that patch will show you where you need to put it. See https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html for more information about where to get a valid certificate file.

(Ralf Lukner MD PhD) #5

Hello @jesdynf,

So if I understand you correctly, all Standard (AWS) “unpatched” versions of OpenEMR 5.0.2 or earlier will stop communicating with their database on or soon after February 5, 2020!

Maybe I’m easily impressed, but this seems to me that it is critical repair of the highest possible degree that all production versions of OpenEMR be upgraded/patched to 5.0.2(1) (or later once more patches are released). Correct me if I’m wrong, but it is my understanding that without the ability to communicate with the database, OpenEMR Standard (AWS) is non-functional.

Also, I do not see the “cert error” fix explicitly listed in the description of the 5.0.2 patch. Could someone a lot more knowledgeable about what is in the releases/patches than me confirm that the “cert error” patch is in 5.0.2(1)?

Thank you,

(Asher Densmore-Lynn) #6

I mean, you’re not wrong, but it’s also not life-or-death panic time; keeping up with a moving target is just life in the cloud. I’m expecting a new version of OpenEMR to come out this week or next, and will be building new GCP and Marketplace packages, and will guarantee that they’ll be ready, but making this fix on your own system? Pretty simple.

  1. Grab the cert file with curl from the AWS document page I linked.
  2. Copy the container’s existing /var/www/localhost/htdocs/openemr/sites/default/documents/certificates/mysql-ca somewhere safe.
  3. Replace the container’s cert file with the new one (and chmod it readable and chown it to the local context.)
  4. Restart the container to pick it up.

Alternately, the text of the patch will give you a hint about how to do it without connecting to the container at all by manipulating the volume manually; be sure to chmod the file properly if you do.

(Ralf Lukner MD PhD) #7


Thank you! That’s an easy fix. I’ll implement it this weekend when the system is in lighter use.

Sure. Over these past 2 years that I have been using OpenEMR, I believe that upgrades/patches of OpenEMR were always enhancements of security, features, repairs of less impactful issues, etc. … patches that did not involve preventing OpenEMR AWS from completely not working anymore … I do not recall even one case where I had to upgrade or patch or my version of OpenEMR would stop working completely, but it sounds like I was spoiled :joy:.

Thank you again!

(Ralf Lukner MD PhD) #8

@jesdynf & @brady.miller
I have applied the 5.0.2 patch 1 … and restarted my AWS EC2 instance.
How do I know if OpenEMR is using the “new” certificates?
I suspect that my now newly patched 5.0.2(1) instance is not using a “new” certificate because I can still connect to the database with OpenEMR. If there was some kind of “new” certificate with SSL/TLS encryption, the “old” database, using the “old” certificate should reject a connection from the openemr using a “new” certificate … correct?

Do I still need to “manually” copy (or “grab” with “curl” somehow) or create a “new” certificate and implement it into OpenEMR somehow? How would I have a secure connection to the mysql database with the “copied” certificate (is there something private that is not copied)?

(Asher Densmore-Lynn) #9

I’m actually not 100% sure the new cert wouldn’t work with the old server. If you want to check, I’d just compare the new certificate to the one you have installed.

As for how you have a secure connection, this is a public SSL certificate issued by Amazon, capable of authenticating a connection to a holder of a key issued by Amazon.