Service Broker for AWS (EOGS 10/31/2020) is not compatible with Go Buildpack v1.9.17 (TAS v2.8.17 update)

Products

• Operations Manager

Issue/Introduction

When updating TAS to v2.8.17, the Go-Buildpack is also updated from v1.9.16 to v1.9.17. The Service Broker for AWS (deprecated) does not support Go Buildpack v1.9.17 and will fail when running the errand "Running errand Deploy Broker for Service Broker for AWS":

2020-09-16T16:20:07.926+02:00 [APP/PROC/WEB/0] [OUT] {"timestamp":"1600266007.925966501","source":"aws-broker","message":"aws-broker.store failed to initialize","log_level":3,"data":{"error":"x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0","trace":"goroutine 1 [running]:\ngithub.com/pivotal-cf/aws-services-broker/vendor/code.cloudfoundry.org/lager.(*logger).Fatal(0xc0001326c0, 0x5556541c1c51, 0x1a, 0x555654809980, 0xc00049f4c0, 0x0, 0x0, 0x0)\n\t/tmp/gobuildpack.gopath797652659/.go/src/github.com/pivotal-cf/aws-services-broker/vendor/code.cloudfoundry.org/lager/logger.go:131 +0xc5\nmain.main()\n\t/tmp/gobuildpack.gopath797652659/.go/src/github.com/pivotal-cf/aws-services-broker/main.go:77 +0x657\n"}} 2020-09-16T16:20:07.928+02:00 [APP/PROC/WEB/0] [ERR] panic: x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0 2020-09-16T16:20:07.928+02:00 [APP/PROC/WEB/0] [ERR] goroutine 1 [running]: 2020-09-16T16:20:07.928+02:00 [APP/PROC/WEB/0] [ERR] github.com/pivotal-cf/aws-services-broker/vendor/code.cloudfoundry.org/lager.(*logger).Fatal(0xc0001326c0, 0x5556541c1c51, 0x1a, 0x555654809980, 0xc00049f4c0, 0x0, 0x0, 0x0) 2020-09-16T16:20:07.928+02:00 [APP/PROC/WEB/0] [ERR] /tmp/gobuildpack.gopath797652659/.go/src/github.com/pivotal-cf/aws-services-broker/vendor/code.cloudfoundry.org/lager/logger.go:152 +0x47e 2020-09-16T16:20:07.928+02:00 [APP/PROC/WEB/0] [ERR] main.main() 2020-09-16T16:20:07.928+02:00 [APP/PROC/WEB/0] [ERR] /tmp/gobuildpack.gopath797652659/.go/src/github.com/pivotal-cf/aws-services-broker/main.go:77 +0x657 2020-09-16T16:20:07.966+02:00 [APP/PROC/WEB/0] [OUT] Exit status 2 2020-09-16T16:20:07.968+02:00 [CELL/SSHD/0] [OUT] Exit status 0 

The errand fails because in Go v1.15, the X.509 CommonName is now deprecated. The deprecated, legacy behavior of treating the CommonName field on X.509 certificates as a host name when no Subject Alternative Names are present is now disabled by default. It can be temporarily re-enabled by adding the value x509ignoreCN=0 to the GODEBUG environment variable.

However, the Certificate in the Broker Config tab for the Service Broker is a AWS certificate so customers won't be able to easily change this right away.

Resolution

Permanent Fix from AWS

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

If you are using a Go version 1.15 application with a DB instance that was created or updated to the rds-ca-2019 certificate prior to July 28, 2020, you must update the certificate again. Run the modify-db-instance command shown in the AWS CLI section using rds-ca-2019 as the CA certificate identifier. In this case, it isn’t possible to update the certificate using the AWS Management Console. If you created your DB instance or updated its certificate after July 28, 2020, no action is required. For more information, see Go GitHub issue #39568.

Temporary Workaround

VMware Support recommends that you apply the permanent workaround described above, but if you are unable to do so, you can temporarily workaround this issue by locking the buildpack, which prevents the buildpack from being updated during upgrades.

By default, when upgrading your deployment, the tools will upload the most recent version of all supported buildpacks. The --lock flag will freeze a buildpack and cause it to not be updated. This lets you continue to use the locked version of the buildpack even after you upgrade. Locked buildpacks are not updated when Cloud Foundry updates. You must manually unlock them to update them.

cf update-buildpack BUILDPACK --lock

If you elect to use the --lock flag, the buildpack will remain locked until you unlock it. You will be responsible for unlocking it. Once you unlock the buildpack, your deployment will resume getting updates.

cf update-buildpack BUILDPACK --unlock

It is important to realize that until you unlock the buildpack, all applications deployed to the foundation that use the Golang buildpack will continue to use the older, locked version of the buildpack. This means that applications will be deployed with an older, potentially vulnerable version of the buildpack.