Add support for Aurora Serverless root certificate

[coreyjv]

Mirror change to this project to align with the node-mysql2 PR here: sidorares/node-mysql2#1026

[dougwilson]

Thanks. Looks like there is a lint issue and also, should this be in the Amazon RDS profile? Isn't Aurora a separate product from RDS? (Don't take this as instructions to split, I'm just asking but ultimately unfamiliar with the AWS products).

[coreyjv]

Thanks. Looks like there is a lint issue and also, should this be in the Amazon RDS profile? Isn't Aurora a separate product from RDS?

Aurora is not a separate product from RDS. Aurora, and Aurora Serverless are additional engines supported by Amazon RDS.

The engines are listed here: https://aws.amazon.com/rds/

[dougwilson]

Ah, thanks. I will get this merged as soon as I can into a new minor release.

[dougwilson]

Since this root certificate seems to be separate from all the rest, even in their documentation (https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.html vs https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html), would anyone object with me adding this cert under a new profile called "Amazon RDS Aurora"?

[coreyjv]

In my case that’d be cumbersome because we connect to serverless Aurora and traditional Aurora interchangeably which means I believe we’d have to start tracking which profile to use with each specific database instead of just using the RDS profile.

[dougwilson]

Right, but that would be the same if you connected to both Amazon RDS and a non Amazon SSL server. The SSL profiles are supposed to reflect each different type of system and not just all possible certificates.

Why would Amazon use a different root CA for RDS vs Aurora? That to me makes it seem like a different SSL profile for how this module is set up. Especially since Amazon went and separated the docs for the Aurora SSL from all the RDS docs.

Of course you can always define your own, custom SSL profile if you wanted to use a single one for convenience.

[coreyjv]

I can't comment on why Amazon would choose a different root CA but from my perspective it's all RDS and when you connect you don't know whether it's Serverless or traditional RDS as that's an implementation detail from the client perspective. I'd prefer we keep the certificate in the same RDS profile.

[dougwilson]

Gotcha, that's what I'm trying to understand. So by you don't know which you are connecting to, does that mean that Amazon just as a single "object" to create on or the other on the backend and they are just interchangeable? They all just share the same domain names or something? Like as an example, you could stand up a MySQL server instance inside AWS, which would end up with different SSL certificates. I'm trying to understand how these two are different, as they are not documented together.

[coreyjv]

The servers are different from an implementation perspective. For example in Serverless Aurora Amazon manages the compute resources automatically whereas in traditional Aurora you manually manage the cluster. From the perspective of a client trying to connect to these databases it's no different. You have a host/port/user/password combination.

[dougwilson]

So it does sound like from the SSL profile perspective they are just as different as if you stood up your own MySQL sevrer -- the certificate for your own server would not be within the existing profile, either. The SSL certificate to trust is an aspect of the host/port combination in this module, currently. You can always make your own, custom profile to trust a different subset of certificates that would encompass all the different types of endpoint you may connect to. This would be no different than if you added another MySQL server to the mix where it was just stood up on a VM inside the AWS environment.

Looking at the Amazon RDS product page https://aws.amazon.com/rds/ seems to list MySQL (the current profile) distinct from Aurora (the SSL cert here). That's probably why they document them separately, as Amazon seems to be indicating they are separate from each other.

[coreyjv]

From Amazon's perspective Aurora and Aurora Serverless are the same product. When you're provisioning an Aurora DB in the AWS Console you pick which one you want. As I mentioned previously from the client's perspective I don't believe it needs to understand the specific Aurora implementation that was chosen only that it's attempting to connect to an Aurora instance and hence use the existing Amazon RDS profile.

[dougwilson]

I mean, the page I linked to above seems to say they are separate "engines":

and provides you with six familiar database engines to choose from, including Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database, and SQL Server.

If there is no page where Amazon just includes all these certs in one location, I am not convinced this is the same thing and they should be the same SSL profile. I am seeing a lot of evidence through out the docs where Amazon treats them as separate things, so it is more apparent to me that these are separate SSL profiles and the only arguments I've hear so far have no evidence that the argument would change if it was a Amazon RDS MySQL instance vs a standalone MySQL VM on AWS.

[coreyjv]

I have a suspicion we're not referring to the same thing. Can you clarify your perspective?

Amazon Aurora is Amazon's engine that is compatible with both MySQL and PostgreSQL. When you provision a MySQL compatible Amazon Aurora engine today you can use the existing Amazon RDS SSL profile. If you provision a MySQL compatible Amazon Aurora serverless engine I believe it should fall under the existing Amazon RDS profile because the fact that it's serverless is an implementation detail. From the API perspective it's still an Amazon Aurora DB that's compatible with MySQL.

[dougwilson]

The RDS page https://aws.amazon.com/rds/ lists 6 different "database engines" to choose from:

and provides you with six familiar database engines to choose from, including Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database, and SQL Server.

Amazon Aurora https://aws.amazon.com/rds/aurora/ is listed distinctly from MySQL https://aws.amazon.com/rds/mysql/

The documentation says that the Amazon Aurora certs are https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.html and the MySQL certs are https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html

In what way are they the "same thing" from the SSL perspective?

[coreyjv]

The existing Amazon RDS profile works for Amazon Aurora databases. My proposal is to add one more Amazon Aurora root cert to that profile.

[dougwilson]

Oh, sorry, I didn't realize that. Which certs in the current profile are Aurora certs?

[coreyjv]

I can't tell you exactly without printing the certs for my Aurora DBs and even then it might not represent both. What I can say however is the Amazon Aurora MySQL docs noted here: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Security.html link directly to these docs for root RDS certs https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.SSL.html

[sehrope]

My read on those docs is:

• For "regular" RDS the certificates are signed by the RDS CA for the region (that's the 2015 one that was rotated for a new 2019 one). The regional RDS CA is signed by the global RDS CA.
• For "serverless" the certificates are signed by their ACM CA (that's the one that's already trusted in browsers).

ACM is the top level they use for automated provisioning for domain validated certificates. After validating that you're in control of a given domain (ex: example.com), they'll let you issue certs for *.example.com. That let's you automatically set up things like HTTP load balancers that identify as "foo.example.com" and have it work in your web browser without cert errors.

For serverless they're using the same infrastructure so the certificate for the DB is signed by the ACM CA. IIUC, it should work out of the box with up to date system level certificate chains as the ACM CA itself is trusted. If not, including that top level CA in the chain alongside the RDS ones should work for both regular and serverless RDS.

Reference:

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.html#aurora-serverless.tls

With Aurora Serverless clusters, you don't need to download and use Amazon RDS SSL/TLS certificates. Instead, use certificates from the AWS Certificate Manager (ACM). For more information, see the AWS Certificate Manager User Guide.
...
When using a mysql or psql client with --ssl-mode VERIFY_CA or VERIFY_IDENTITY, specify the --ssl-ca option pointing to a CA in .pem format. For a .pem file that you can use, download the Amazon Root CA 1 trust store from Amazon Trust Services.

That last part links to this cert: https://www.amazontrust.com/repository/AmazonRootCA1.pem

$ curl -s https://www.amazontrust.com/repository/AmazonRootCA1.pem | openssl x509 -text -noout 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            06:6c:9f:cf:99:bf:8c:0a:39:e2:f0:78:8a:43:e6:96:36:5b:ca
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Amazon, CN = Amazon Root CA 1
        Validity
            Not Before: May 26 00:00:00 2015 GMT
            Not After : Jan 17 00:00:00 2038 GMT
        Subject: C = US, O = Amazon, CN = Amazon Root CA 1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:b2:78:80:71:ca:78:d5:e3:71:af:47:80:50:74:
                    7d:6e:d8:d7:88:76:f4:99:68:f7:58:21:60:f9:74:
                    84:01:2f:ac:02:2d:86:d3:a0:43:7a:4e:b2:a4:d0:
                    36:ba:01:be:8d:db:48:c8:07:17:36:4c:f4:ee:88:
                    23:c7:3e:eb:37:f5:b5:19:f8:49:68:b0:de:d7:b9:
                    76:38:1d:61:9e:a4:fe:82:36:a5:e5:4a:56:e4:45:
                    e1:f9:fd:b4:16:fa:74:da:9c:9b:35:39:2f:fa:b0:
                    20:50:06:6c:7a:d0:80:b2:a6:f9:af:ec:47:19:8f:
                    50:38:07:dc:a2:87:39:58:f8:ba:d5:a9:f9:48:67:
                    30:96:ee:94:78:5e:6f:89:a3:51:c0:30:86:66:a1:
                    45:66:ba:54:eb:a3:c3:91:f9:48:dc:ff:d1:e8:30:
                    2d:7d:2d:74:70:35:d7:88:24:f7:9e:c4:59:6e:bb:
                    73:87:17:f2:32:46:28:b8:43:fa:b7:1d:aa:ca:b4:
                    f2:9f:24:0e:2d:4b:f7:71:5c:5e:69:ff:ea:95:02:
                    cb:38:8a:ae:50:38:6f:db:fb:2d:62:1b:c5:c7:1e:
                    54:e1:77:e0:67:c8:0f:9c:87:23:d6:3f:40:20:7f:
                    20:80:c4:80:4c:3e:3b:24:26:8e:04:ae:6c:9a:c8:
                    aa:0d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Subject Key Identifier: 
                84:18:CC:85:34:EC:BC:0C:94:94:2E:08:59:9C:C7:B2:10:4E:0A:08
    Signature Algorithm: sha256WithRSAEncryption
         98:f2:37:5a:41:90:a1:1a:c5:76:51:28:20:36:23:0e:ae:e6:
         28:bb:aa:f8:94:ae:48:a4:30:7f:1b:fc:24:8d:4b:b4:c8:a1:
         97:f6:b6:f1:7a:70:c8:53:93:cc:08:28:e3:98:25:cf:23:a4:
         f9:de:21:d3:7c:85:09:ad:4e:9a:75:3a:c2:0b:6a:89:78:76:
         44:47:18:65:6c:8d:41:8e:3b:7f:9a:cb:f4:b5:a7:50:d7:05:
         2c:37:e8:03:4b:ad:e9:61:a0:02:6e:f5:f2:f0:c5:b2:ed:5b:
         b7:dc:fa:94:5c:77:9e:13:a5:7f:52:ad:95:f2:f8:93:3b:de:
         8b:5c:5b:ca:5a:52:5b:60:af:14:f7:4b:ef:a3:fb:9f:40:95:
         6d:31:54:fc:42:d3:c7:46:1f:23:ad:d9:0f:48:70:9a:d9:75:
         78:71:d1:72:43:34:75:6e:57:59:c2:02:5c:26:60:29:cf:23:
         19:16:8e:88:43:a5:d4:e4:cb:08:fb:23:11:43:e8:43:29:72:
         62:a1:a9:5d:5e:08:d4:90:ae:b8:d8:ce:14:c2:d0:55:f2:86:
         f6:c4:93:43:77:66:61:c0:b9:e8:41:d7:97:78:60:03:6e:4a:
         72:ae:a5:d1:7d:ba:10:9e:86:6c:1b:8a:b9:59:33:f8:eb:c4:
         90:be:f1:b9

You likely have that cert already in your local /etc/ssl/certs. I'm not sure if node / this driver falls back to verifying against that system wide trust store (maybe it only does that if the cert fields are totally blank). If not then including it in the chain should work and I think cover things up to 2038.

[dougwilson]

Thanks for that information @sehrope . So it sounds like the serverless RDS is set up with different certificate chains because it seems like the profile this module has is basically "legacy". I found even more information on this, and it seems like Amazon operates it's own set of CAs for all services managed though ACM. All of those roots (including the one included in this PR) can be found here: https://www.amazontrust.com/repository/

It seems like we should add a new profile to this module called simply "Amazon" and include all these core Amazon CAs. The Amazon RDS profile can stay the same with the current CAs that are specific to RDS. The main difference is that the current Amazon RDS profile will only trust actual Amazon RDS endpoints, while the new Amazon profile (which includes this cert) can trust any service one wants to set up on Amazon.

But even that is likely unnecessary, as those Amazon CAs (including the one added here) is signed by Starfield Services Root Certificate Authority - G2, which is in turn signed by Starfield Class 2 Certification Authority. Node.js already trusts this, and so connecting to these services is already trusted by Node.js without a custom profile needed at all :) !