This message was deleted.

@creamy-pencil-82913 I used the ca.pem, client-key.pem and client-cert.pem accordingly. But seems to be problem here. Not sure what is causing the problem here. HeidiSQL is taking these openssl generated files and perfectly connecting to the db server without any problem even with the nlb endpoint.

https://lmgtfy.app/?q=certificate+is+not+valid+for+any+names Your cert has no subectAlternativeNames and they are required by most (but not all) software these days. Stop randomly tag-spamming people without even googling your problem. 2/3 of us don't even work for Rancher/SUSE any more.

I tried adding subectAlternativeNames to my certificates. Still no luck. I did google and tried many ways to make it work. But still it did not work and that's why I posted the question here. Remind me something please, this is a k3s support slack right?

From a community, yes. From a list of individual people who would have seen your message and answered if they wanted to but you're now individually spamming at 3am local, no. Employees have a cow head by their names, but tagging them on random questions is not really any better. Readers only know what you tell them. If you ask a question and present no evidence that you've done anything to find the obvious answer, that's what you're going to get, if anything. K3s isn't making that message up out of nowhere, you're still serving a cert with no SANs.

It shows 12:27 PM Local Time for you. And I am trying to solve this error since yesterday when I posted this question. I am trying to generate certificates using openssl with the SAN and also I used mkcert just now still with no luck. Is k3s caching the previous certificates somewhere else and keeps deploying them without deploying what I set on the environment variables as ca,cert and key files? Sorry about less information on the question. I myself not sure what information would help understand my question better. I am newbie with SSL and TLS in general.

That's because I'm on a cruise ship in the middle of the ocean in the Arctic circle by Norway awake and answering the notification you created on a thread you added me to, instead of at home at 3am where Darren is.

Nevermind vincent. You can delete the thread if you want. I will figure it out by myself one day. Don't worry. Wasn't expecting so much unnecessary talk on a simple support question. Sorry about disturbing you on a cruise ship. Have fun.

My point is it stops being a simple support question once you're individually picking out a list of people you want answers from. The satellite internet barely works to text up here, but find the command to get the cert being actually returned with openssl and then print it out in plain text. I think

openssl s_client

has a flag like showCerts or something. I don't think k3s has anything to do with your problem and you'll find the cert returned still has no SANs.

this is the k3s-cert.pem file that I am providing as the certfile parameter on k3s

The one that matters here is what's being served up by the mysql server.. the one you give to k3s is just to tell it that the cert it receives should be trusted because you're saying so, even though it's not signed by a normally trusted CA

So, I have to set the SANs inside mysql server certificates? Have to recreate both the client and server certificates here with the SAN? Even the CA?

When you open a TLS connection the client says "hello I'm looking for blah.com and here's some random numbers" and the server replies "here is a certificate and some more numbers that we can now both use to encrypt further communication". The server can use the blah.com part to decide which cert to return (which is mostly relevant for web hosting, you only have one cert for the server). The client then looks at the cert returned to see if it is for the blah.com it asked for. There's a single "subject" in the cert which is mostly ignored these days, and a list of SANs. Your error is saying it for a cert that has no SAN list. Then if that's ok the client decides if it trusts the cert it got, which usually means it has been signed by a parent/CA cert it does trust. Or that you've explicitly given it the same cert to say that's the one you're expecting.

openssl req -newkey rsa:4096 -nodes -days 36500 -keyout server-key.pem -out server-req.pem -addext "subjectAltName=DNSk3s,IPx.x.x."

Client certificates are another layer after all that above, to allow the server to verify/identify the client they're talking to. You don't need them at all just to use the database, unless you really want it

I put the client certificate, key and ca file on heidisql to connect to the mysql server. Just to visualize the database.

👍 It's basically the same idea as a regular cert, but in reverse. Normally the client is connecting to a (so far) untrusted server and verifying they are who they claim to be (by proving the server has a certificate signed by a certificate authority you do already trust). Client cert is the opposite, after all that above the client provides it's own cert identifying itself that the server can then verify. It's normally used as basically a more complicated form of username+password to say who you are to the service you're connecting to. There's not any particularly compelling reason to use it to talk to your database vs user/pass.

Understood. So, basically it can be used to replace the whole user/pass authentication system of mysql. Will it work in conjunction with the user/pass system at place?