Question: I have created an AMAZON RDS mariadb database under free tier.

I used a random generated password first but it is not connecting.

So, I click modify and updated the database with new password.

but still, I am getting error as below.

```
(conn=36) Access denied for user 'root'@'175.101.107.213' (using password: YES)
Current charset is windows-1252. If password has been set using other charset, consider using option 'passwordCharacterEncoding'

```

[![enter image description here](https://i.stack.imgur.com/mPJCI.png)](https://i.stack.imgur.com/mPJCI.png)

But I updated the password multiple times but same issue everytime.

Please suggest how to fix that.
I checked the passwordCharacterEncoding option in the dbeaver, it is having an empty value.

Answer: 
First off, I have not seen any specific information regarding the contents of the ssl\_version field in ELB logs, which would be the correct place to authoritatively answer what the ELB logs mean.

That said, in this kind of context the string `TLSv1` should reasonably be interpreted to mean *TLS version 1.0*.  

In your particular case, this would imply that those clients do not seem to support higher versions (because they would be expected to prefer and use those whenever possible).

It is worth noting that strings like `SSLv2`, `SSLv3`, `TLSv1`, `TLSv1.1`, `TLSv1.2`, `TLSv1.3` especially when written just like this (and sometimes minor variations on the theme, depending on the software involved) are often not free-form text crafted with the exact current context in mind, but rather protocol identifiers used in the underlying software.

As for the potentially confusing `TLSv1` identifier widely used for TLS version 1.0, I think what we can read into this is simply that popular implementations (like openssl) were kind of caught out by the change of versioning policy that became clear only when TLS 1.1 and the following versions were introduced much later.  

Ie, SSL had been versioned 1.0, 2.0, 3.0, but since the protocol changed names to TLS the versions have instead followed the pattern 1.0, 1.1, 1.2, 1.3. At the time when TLS 1.0 was first introduced, I guess that the assumption simply was that the next version would be 2.0 and that continuing the same pattern of simplified identifiers like before would continue to make sense.

Sidenote:  

It is correct that `curl` has command line options that makes clever use of `--tlsv1` meaning something different than `--tlsv1.0`, but the question is not about how to instruct `curl` how it is allowed to connect, but rather to parse what a log entry specifies as the exact version a certain connection used.
It's your choice if you want to allow user to fallback to lower version (which off course have vulnerabilities like poodle) or reject if cipher or tls version is not matching. You have to communicate to end user/client from here you have to use mentioned version else connection will be rejected.

So, now if client explicitly says I want to use lower version of TLS but from server you are preventing old version, client will not upgrade version at all. In this case request will be rejected.