GODRIVER-2263 changes the driver's certificate parsing behavior to only parse the first certificate rather than the last certificate, despite the ticket title suggesting that all certificates are being loaded.

In that ticket, while all certificates are concatenated with newlines by the driver and passed to tls.X509KeyPair(), and while tls.X509KeyPair() iterates over all certificates and un-concatenates them using pem.Decode(), the tls.X509KeyPair() function always statically takes the first certificate anyway. So providing all certificates to tls.X509KeyPair(), rather than the first or last one, doesn't do much.

Ultimately, this changes the behavior of the Go driver from using the last certificate to now using the first certificate. Still, this is not an issue in itself since it aligns with OpenSSL and other libraries' behaviors, which also use the first certificate if multiple are provided. On the whole, the only concern with GODRIVER-2263 is that the ticket's title is a bit misleading.

But there is a separate problem w.r.t. which certificate is used as the username for X509 auth. When the Go driver loops over the certificates, the certDecodedBlock variable takes on the last value (the last certificate). This certificate's Subject is returned as a string at the end of that function, and this later has an erroneous value when setting the connection string's username if there is more than one certificate per PEM file, since it doesn't correspond to the behavior changed by GODRIVER-2263.

So for this ticket, the work is simple. This can be fixed by changing this line:

certDecodedBlock = currentBlock.Bytes 

to this:

if certDecodedBlock == nil {
    certDecodedBlock = currentBlock.Bytes 
} 

This will make certDecodedBlock take on the value of the first certificate, aligning it with the behavior introduced in GODRIVER-2263.