After updating certificates of existing etcd nodes from ip in san to Dns we are getting error

[Singh02306]

What would you like to be added?

We recently updated our certificate for etcd members and new certificate doesn't caontain ip in San, while starting etcd nodes error is coming that certificate doesn't have ip San.
If we change data directory and then start the nodes with certs cluster is coming up fine.

Why is this needed?

How do we make etcd work in this scenario.

[jmhbnz]

Hi @Singh02306 - Thanks for raising this question. For us to investigate any further can you please provide:

• Your etcd version & configuration options used
• A test certificate in text format
• The logs of the etcd instance that is not starting as you expect

I note there is some related discussion for issues around subject alternative names here which might be of interest #8603.

[Singh02306]

Hi @jmhbnz

etcd 3.4.13
my new config after certificate changes:
_name: 'infra2'
data-dir: /data/infra2/
listen-peer-urls: https://10.0.219.56:2380
listen-client-urls: https://127.0.0.1:2379,https://10.0.219.56:2379
initial-advertise-peer-urls: https://etcd-controlplane1.uat.hk.net:2380
advertise-client-urls: https://etcd-controlplane1.uat.hk.net:2379
initial-cluster: infra0=https://etcd-controlplane2.uat.hk.net:2380,infra1=https://etcd-controlplane2.uat.hk.net:2301,infra2=https://etcd-controlplane1.uat.hk.net:2380
initial-cluster-token: 'cluster1'
initial-cluster-state: 'new'
client-transport-security:
cert-file: /certs/etcd1.pem

key-file: /certs/etcd1.key

client-cert-auth: true

trusted-ca-file: /certs/hCA.crt

auto-tls: false

peer-transport-security:

cert-file: /certs/etcd1.pem

key-file: /certs/etcd1.key

trusted-ca-file: /certs/hCA.crt

auto-tls: false_

my old config was like below:
name: 'infra2'
data-dir: /data/infra2/
listen-peer-urls: https://10.0.219.56:2380
listen-client-urls: https://127.0.0.1:2379,https://10.0.219.56:2379
initial-advertise-peer-urls: https://10.0.219.56:2380
advertise-client-urls: https://10.0.219.56:2379
initial-cluster: infra0=https://10.0.219.57:2380,infra1=https://10.0.219.57:2301,infra2=https://10.0.219.56:2380
initial-cluster-token: 'cluster1'
initial-cluster-state: 'new'
followed by certificate paths

Error: x509: cannot validate certificate for 10.0.219.57 because it doesn't contain any IP SANs"}

[Singh02306]

same config in other two nodes as well just the location and ip/DNS change.....

[jmhbnz]

Hi @Singh02306 - Thanks for providing some of the information, can you also please provide:

• A test certificate in text format

You can redact some fields if necessary.

Additionally - this is a tangent but the release of etcd you are running is three years old. Many bugs and security vulnerabilities have been addressed in later versions of etcd, you should update as soon as possible.

[Singh02306]

Hi @jmhbnz ,

updated the etcd version to 3.5.0 still same error....sorry certificate contents i won't be able to update here.

[jmhbnz]

Thanks for the update @Singh02306, please try the latest 3.5.x release.

For the certificate, I'm not asking you post the whole thing, you can convert it to text with openssl x509 -in cert.pem -text -noout and post the generic fields, redacting as neccessary. The main thing we need to compare against is how the subject alternative names are set.

[Singh02306]

hi @jmhbnz ,

contents of the cert:

X509v3 extensions:
X509v3 Subject Key Identifier:
E0:6C:CC:2A::
X509v3 Subject Alternative Name:
DNS:etcd-controlplane1.uat.hk.net
X509v3 Authority Key Identifier:
keyid::
X509v3 Key Usage:
Digital Signature, Key Encipherment
1.3.6.1.4.1.311.21.7:
0..&+.....7.....C...:.......'...3.h...c..f..d..(
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication

[jmhbnz]

Thanks @Singh02306 - You mention updating to 3.5.0, that is a two year old release, can you please confirm the issue is still present on the latest patch release of 3.5, i.e. 3.5.9?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.