I am starting kubernetes api server(v1.15.3) using this command:
systemctl start kube-apiserver.service
this is the log output:
● kube-apiserver.service - Kubernetes API Service
Loaded: loaded (/usr/lib/systemd/system/kube-apiserver.service; enabled; vendor preset: disabled)
Active: activating (start) since 六 2019-08-24 20:12:18 CST; 4s ago
Docs: https://github.com/GoogleCloudPlatform/kubernetes
Main PID: 9563 (kube-apiserver)
Tasks: 13
Memory: 11.0M
CGroup: /system.slice/kube-apiserver.service
└─9563 /usr/local/bin/kube-apiserver --logtostderr=true --v=0 --etcd-servers=https://172.19.104.231:2379,https://172.19.104.230:2379,https://172.19.150.82:2379 --advertise-address=172.19.104.231 --bind-address=172.19.104.231 --insecure-bind-address=172.19.104.231 --allow-privileged=true --service-cluster-ip-range=10.254.0.0/16 --admission-control=ServiceAccount,NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQuota --authorization-mode=RBAC --runtime-config=rbac.authorization.k8s.io/v1beta1 --kubelet-https=true --enable-bootstrap-token-auth --token-auth-file=/etc/kubernetes/token.csv --service-node-port-range=30000-32767 --tls-cert-file=/etc/kubernetes/ssl/kubernetes.pem --tls-private-key-file=/etc/kubernetes/ssl/kubernetes-key.pem --client-ca-file=/etc/kubernetes/ssl/ca.pem --service-account-key-file=/etc/kubernetes/ssl/ca-key.pem --etcd-cafile=/etc/kubernetes/ssl/ca.pem --etcd-certfile=/etc/kubernetes/ssl/kubernetes.pem --etcd-keyfile=/etc/kubernetes/ssl/kubernetes-key.pem --enable-swagger-ui=true --apiserver-count=3 --audit-log-maxage=30 --audit-log-maxbackup=3 --audit-log-maxsize=100 --audit-log-path=/var/lib/audit.log --event-ttl=1h
8月 24 20:12:19 iZuf63refzweg1d9dh94t8Z kube-apiserver[9563]: W0824 20:12:19.994504 9563 clientconn.go:1251] grpc: addrConn.createTransport failed to connect to {172.19.150.82:2379 0 <nil>}. Err :connection error: desc = "transport: authentication handshake failed: x509: certificate signed by unknown authority (possibly because of \"crypto/rsa: verification error\" while trying to verify candidate authority certificate \"kubernetes\")". Reconnecting...
8月 24 20:12:20 iZuf63refzweg1d9dh94t8Z kube-apiserver[9563]: W0824 20:12:20.985988 9563 clientconn.go:1251] grpc: addrConn.createTransport failed to connect to {172.19.104.231:2379 0 <nil>}. Err :connection error: desc = "transport: authentication handshake failed: x509: certificate signed by unknown authority (possibly because of \"crypto/rsa: verification error\" while trying to verify candidate authority certificate \"kubernetes\")". Reconnecting...
8月 24 20:12:20 iZuf63refzweg1d9dh94t8Z kube-apiserver[9563]: W0824 20:12:20.986331 9563 clientconn.go:1251] grpc: addrConn.createTransport failed to connect to {172.19.104.230:2379 0 <nil>}. Err :connection error: desc = "transport: authentication handshake failed: x509: certificate signed by unknown authority (possibly because of \"crypto/rsa: verification error\" while trying to verify candidate authority certificate \"kubernetes\")". Reconnecting...
this CA certificate of kubernetes config(kubernetes-csr.json):
{
"CN": "kubernetes",
"hosts": [
"127.0.0.1",
"172.19.104.230",
"172.19.150.82",
"172.19.104.231"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "BeiJing",
"L": "BeiJing",
"O": "k8s",
"OU": "System"
}
]
}
What should I do to fix this problem?I have tried self sign certificate in CentOS 7:
openssl x509 -outform der -in kubernetes.pem -out kubernetes.crt
cp /data/k8s/ssl/kubernetes.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust
My etcd cluster using the same certification file.This is the generate certificate command:
$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kubernetes-csr.json | cfssljson -bare kubernetes
this is the etcd list:
[root#iZuf63refzweg1d9dh94t8Z ssl]# etcdctl member list
55a782166ce91d01, started, infra3, https://172.19.150.82:2380, https://172.19.150.82:2379
67bca27e43a8258a, started, infra2, https://172.19.104.230:2380,
696a771758a889c4, started, infra1, https://172.19.104.231:2380, https://172.19.104.231:2379
This may caused by your certificate file generate encount warning,you should use new version of cfssl(above v1.2),and make sure have no warning.This is cause by this tip when using cfssl(v1.3) to generate certificate:
This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements")
try to upgrade the cfssl to v1.3.4 and regenerate certificate.
/usr/local/go/bin/go get -u github.com/cloudflare/cfssl/cmd/cfssl
verify the version.
[root#iZuf63refzweg1d9dh94t8Z ssl]# /root/go/bin/cfssl version
Version: 1.3.4
Revision: dev
Runtime: go1.12.9
Related
I have Hyperledger Fabric (1.3) network which had expired certificates.
I was not able to execute peer chaincode commands.
I have generated certificates using same ca server and replaced. Now I am able to run query commands but still getting following error on peer for invoke,
2022-11-23 15:07:01.440 UTC [grpc] createTransport -> DEBU 0be grpc:
addrConn.createTransport failed to connect to {orderer1:7050 0 <nil>}. Err :connection error:
desc = "transport: authentication handshake failed: remote error: tls: bad certificate". Reconnecting...
Kindly help. Any suggestion will be appreciated.
I have three node MongoDB cluster in GCP kubernetes cluster following [1], [2]. I can properly connect with tls=false using mongosh client. Then I enabled tls following [3]. Mongo cluster start properly but I cannot connect from mongosh.
Following is the connection details.
{
"connectionString.standard": "mongodb://mongo-user:stl-m0ng0-dev#mongodb-dev-0.mongodb-dev-svc.dev.svc.cluster.local:27017,mongodb-dev-1.mongodb-dev-svc.dev.svc.cluster.local:27017,mongodb-dev-2.mongodb-dev-svc.dev.svc.cluster.local:27017/dev?replicaSet=mongodb-dev&ssl=true",
"connectionString.standardSrv": "mongodb+srv://mongo-user:stl-m0ng0-dev#mongodb-dev-svc.dev.svc.cluster.local/dev?replicaSet=mongodb-dev&ssl=true",
"password": "xxxxxxx",
"username": "mongo-user"
}
Followings are the certificate details.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = TLSGenSelfSignedtRootCA, L = $$$$
Validity
Not Before: Jul 27 09:07:50 2022 GMT
Not After : Jul 24 09:07:50 2032 GMT
Subject: CN = *.mongodb-dev-svc.dev.svc.cluster.local, O = client
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:c4:44:a6:21:95:85:9a:dc:96:63:8e:76:ed:d9:
3a:59
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Subject Alternative Name:
DNS:mongodb-dev-1.mongodb-dev-svc.dev.svc.cluster.local, DNS:mongodb-dev-2.mongodb-dev-svc.dev.svc.cluster.local, DNS:mongodb-dev-3.mongodb-dev-svc.dev.svc.cluster.local
Signature Algorithm: sha256WithRSAEncryption
7b:78:43:73:ae:2f:ce:97:de:b2:19:56:4c:38:71:8e:3d:ff:
5b:15:79:c1
Will display server certificate info
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = TLSGenSelfSignedtRootCA, L = $$$$
Validity
Not Before: Jul 27 09:07:50 2022 GMT
Not After : Jul 24 09:07:50 2032 GMT
Subject: CN = *.mongodb-dev-svc.dev.svc.cluster.local, O = server
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:bc:1e:4a:a7:4f:c4:01:71:2c:78:eb:ac:c9:53:
24:c1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:mongodb-dev-0.mongodb-dev-svc.dev.svc.cluster.local, DNS:mongodb-dev-1.mongodb-dev-svc.dev.svc.cluster.local, DNS:mongodb-dev-2.mongodb-dev-svc.dev.svc.cluster.local
Signature Algorithm: sha256WithRSAEncryption
16:0f:09:02:66:05:69:7b:91:3b:93:73:86:64:d5:8f:53:2d:
08:19:68:a7
Client side has following error
root#xxxxxxxxxxxxxxxxxx-55955c9fcd-bpp98:/usr/src/app# mongosh "mongodb+srv://mongo-user:stl-m0ng0-dev#mongodb-dev-svc.dev.svc.cluster.local/dev?replicaSet=mongodb-dev&ssl=false&tlsCAFile=ca.pem&tlsCertificateKeyFile=key.pem"
Current Mongosh Log ID: 62e1029487b960f1bd204b1d
Connecting to: mongodb+srv://<credentials>#mongodb-dev-svc.dev.svc.cluster.local/dev?replicaSet=mongodb-dev&ssl=false&tlsCAFile=ca.pem&tlsCertificateKeyFile=key.pem&appName=mongosh+1.5.1
MongoServerSelectionError: connection <monitor> to 10.120.6.8:27017 closed
Server side has following error
2022-07-27T09:25:44.992+0000 I NETWORK [conn25852] end connection 10.120.6.9:33914 (14 connections now open)
2022-07-27T09:25:44.993+0000 I NETWORK [listener] connection accepted from 10.120.6.9:33918 #25855 (15 connections now open)
2022-07-27T09:25:44.993+0000 E NETWORK [conn25854] SSL peer certificate validation failed: unsupported certificate purpose
2022-07-27T09:25:44.994+0000 I NETWORK [conn25854] Error receiving request from client: SSLHandshakeFailed: SSL peer certificate validation failed: unsupported certificate purpose. Ending connection from 10.120.8.127:58220 (connection id: 25854)
2022-07-27T09:25:44.994+0000 I NETWORK [conn25854] end connection 10.120.8.127:58220 (14 connections now open)
2022-07-27T09:25:44.995+0000 I NETWORK [listener] connection accepted from 10.120.8.127:58224 #25856 (15 connections now open)
2022-07-27T09:25:44.998+0000 E NETWORK [conn25855] SSL peer certificate validation failed: unsupported certificate purpose
2022-07-27T09:25:44.998+0000 I NETWORK [conn25855] Error receiving request from client: SSLHandshakeFailed: SSL peer certificate validation failed: unsupported certificate purpose. Ending connection from 10.120.6.9:33918 (connection id: 25855)
2022-07-27T09:25:44.998+0000 I NETWORK [conn25855] end connection 10.120.6.9:33918 (14 connections now open)
2022-07-27T09:25:45.000+0000 E NETWORK [conn25856] SSL peer certificate validation failed: unsupported certificate purpose
2022-07-27T09:25:45.000+0000 I NETWORK [conn25856] Error receiving request from client: SSLHandshakeFailed: SSL peer certificate validation failed: unsupported certificate purpose. Ending connection from 10.120.8.127:58224 (connection id: 25856)
2022-07-27T09:25:45.000+0000 I NETWORK [conn25856] end connection 10.120.8.127:58224 (13 connections now open)
2022-07-27T09:25:45.001+0000 I REPL_HB [replexec-2] Heartbeat to mongodb-dev-1.mongodb-dev-svc.dev.svc.cluster.local:27017 failed after 2 retries, response status: HostUnreachable: stream truncated
2022-07-27T09:25:45.003+0000 I NETWORK [listener] connection accepted from 10.120.8.127:58228 #25858 (14 connections now open)
2022-07-27T09:25:45.007+0000 E NETWORK [conn25858] SSL peer certificate validation failed: unsupported certificate purpose
2022-07-27T09:25:45.007+0000 I NETWORK [conn25858] Error receiving request from client: SSLHandshakeFailed: SSL peer certificate validation failed: unsupported certificate purpose. Ending connection from 10.120.8.127:58228 (connection id: 25858)
2022-07-27T09:25:45.007+0000 I NETWORK [conn25858] end connection 10.120.8.127:58228 (13 connections now open)
Operator log has TLS configuration issue.
2022-07-27T10:06:05.893Z INFO controllers/mongodb_status_options.go:110 TLS config is not yet valid, retrying in 10 seconds
2022-07-27T10:06:15.899Z INFO controllers/replica_set_controller.go:140 Reconciling MongoDB {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG controllers/replica_set_controller.go:142 Validating MongoDB.Spec {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG controllers/replica_set_controller.go:151 Ensuring the service exists {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG agent/agent_readiness.go:101 The Pod '' doesn't have annotation 'agent.mongodb.com/version' yet {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG agent/agent_readiness.go:101 The Pod '' doesn't have annotation 'agent.mongodb.com/version' yet {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG agent/agent_readiness.go:101 The Pod '' doesn't have annotation 'agent.mongodb.com/version' yet {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG agent/replica_set_port_manager.go:122 No port change required {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.906Z INFO controllers/replica_set_controller.go:462 Create/Update operation succeeded {"ReplicaSet": "dev/mongodb-replica-set","operation": "updated"}
2022-07-27T10:06:15.906Z INFO controllers/mongodb_tls.go:40 Ensuring TLS is correctly configured {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.906Z WARN controllers/mongodb_tls.go:47 CA resource not found: Secret "tls-ca-key-pair" not found {"ReplicaSet": "dev/mongodb-replica-set"}
[1]. https://github.com/mongodb/mongodb-kubernetes-operator/blob/v0.7.4/docs/install-upgrade.md
[2]. https://github.com/mongodb/mongodb-kubernetes-operator/blob/v0.7.4/docs/deploy-configure.md
[3]. https://github.com/mongodb/mongodb-kubernetes-operator/blob/v0.7.4/docs/secure.md
It had two main reasons.
I followed [1] to enable SSL. It create another Statefulset. After that there are two mongo servers. Uninstall operator and re-install and followed last stable release documentation [2]. After it properly detect configmap and secret.
But it gave SSL issue in certificates as Unsupported Certificate in server modules. Following [3] found the issue. We need to remove extended_key_useage from openssl.conf. Otherwise it not work properly.
Important thread [4]
Hope this help.
[1]. https://github.com/mongodb/mongodb-kubernetes-operator/blob/master/docs/secure.md
[2]. https://github.com/mongodb/mongodb-kubernetes-operator/blob/v0.7.4/docs/secure.md
[3]. https://stackoverflow.com/a/61964464/5607943
[4]. https://groups.google.com/g/mongodb-user/c/EmESxx5KK9Q/m/xH6Ul7fTBQAJ
I am trying to configure a demo, cross-platform Puppet Setup, that is
Puppet master on Centos 8 running puppetserver version: 6.11.1
Puppet node on ubuntu18.04 running Puppet v5.4.0
However, when I try a test puppet run with puppet agent --test , I get error like below.
Looks like it is expecting a issuer certificate of Puppet CA , that is certificate of the root CA which signed the puppet CAs certficate. This error is not present with centosMaster-centosUbuntu.
Can anyone helpout here? Can i copy this cert from the Puppet servers file on centos to the ubuntu node that is expecting it? If so what would be the location on the centos host?
root#node04-ubuntu:/# puppet agent --test --ca_server=puppetmaster.localdomain.com --no-daemonize --waitforcert=20 --verbose
Warning: Unable to fetch my node definition, but the agent run will continue:
Warning: SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get issuer certificate): [unable to get issuer certificate for /CN=Puppet CA: puppetmaster.localdomain.com]
Info: Retrieving pluginfacts
Error: /File[/var/cache/puppet/facts.d]: Failed to generate additional resources using 'eval_generate': SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get issuer certificate): [unable to get issuer certificate for /CN=Puppet CA: puppetmaster.localdomain.com]
Error: /File[/var/cache/puppet/facts.d]: Could not evaluate: Could not retrieve file metadata for puppet:///pluginfacts: SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get issuer certificate): [unable to get issuer certificate for /CN=Puppet CA: puppetmaster.localdomain.com]
Info: Retrieving plugin
Error: /File[/var/cache/puppet/lib]: Failed to generate additional resources using 'eval_generate': SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get issuer certificate): [unable to get issuer certificate for /CN=Puppet CA: puppetmaster.localdomain.com]
Error: /File[/var/cache/puppet/lib]: Could not evaluate: Could not retrieve file metadata for puppet:///plugins: SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get issuer certificate): [unable to get issuer certificate for /CN=Puppet CA: puppetmaster.localdomain.com]
Error: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get issuer certificate): [unable to get issuer certificate for /CN=Puppet CA: puppetmaster.localdomain.com]
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
Error: Could not send report: SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get issuer certificate): [unable to get issuer certificate for /CN=Puppet CA: puppetmaster.localdomain.com
Fixed
The issue was the version mismatch. Got the client to be as the same latest version as the master and it is working now. Cheers
I am trying to test a mongoDB installation with self signed certificates. I followed the instructions in the mongoDB documentation for creating the 'pem' files using the copy links on each page:
Appendix A - OpenSSL CA Certificate for Testing
Appendix B - OpenSSL Server Certificates for Testing
Appendix C - OpenSSL Client Certificates for Testing
I updated the /etc/mongod.conf as such:
# network interfaces
net:
port: 27017
bindIp: 0.0.0.0
tls:
mode: requireTLS
certificateKeyFile: /etc/ssl/mongodb/test-server1.pem
allowConnectionsWithoutCertificates: true
allowInvalidHostnames: true
allowInvalidCertificates: true
CAFile: /etc/ssl/mongodb/mongodb-test-ca.crt
Originally I did not have the 'allow' option, but they do not make a difference so I am leaving the in for now.
Running the mongodb shell results in this error:
root#ip-10-0-3-61:~/mongo-cert# mongo --tls --tlsCertificateKeyFile test-client.pem
MongoDB shell version v4.2.5
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
2020-04-17T17:07:25.809+0000 E NETWORK [js] SSL peer certificate validation failed: self signed certificate in certificate chain
2020-04-17T17:07:25.810+0000 E QUERY [js] Error: couldn't connect to server 127.0.0.1:27017, connection attempt failed: SSLHandshakeFailed: SSL peer certificate validation failed: self signed certificate in certificate chain :
connect#src/mongo/shell/mongo.js:341:17
#(connect):2:6
2020-04-17T17:07:25.812+0000 F - [main] exception: connect failed
2020-04-17T17:07:25.812+0000 E - [main] exiting with code 1
root#ip-10-0-3-61:~/mongo-cert#
If I add the '--tlsAllowInvalidCertificates' in the command it works:
root#ip-10-0-3-61:~/mongo-cert# mongo --tls --tlsCertificateKeyFile test-client.pem --tlsAllowInvalidCertificates
MongoDB shell version v4.2.5
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
2020-04-17T17:09:18.934+0000 W NETWORK [js] SSL peer certificate validation failed: self signed certificate in certificate chain
Implicit session: session { "id" : UUID("3b0d0920-931d-4143-a8a2-afde432c1444") }
MongoDB server version: 4.2.5
>
I have read other people who have followed the mongodb instructions successfully.
I just do not understand what I have done wrong.
You need to provide the CA file to mongo also (the --tlsCAFile option), in addition to the client certificate.
When full verification is enabled with TLS both server and client validate the other's certificate. This means both must have access to the CA cert used for signing the leaf certs.
I have used kubeadm alpha phase certs to recreate the certificates used in my Kubernetes cluster. Also, use the alpha phase for kubeconfig. Now when trying to join a new worker - it is giving me errors that my token is invalid even when the token has been regenerate 3 times using - kubeadm token create --print-join-command.
The error that I keep getting is:
[discovery] Created cluster-info discovery client, requesting info from "https://x.x.x.x:6443"
[discovery] Failed to connect to API Server "x.x.x.x:6443": token id "bvw4cz" is invalid for this cluster or it has expired. Use "kubeadm token create" on the master node to creating a new valid token
Anyone run into the same problems or have a suggestion?
Thanks!
EDIT--
This is the tail end of /var/log/syslog --
Nov 5 09:40:01 master01 kubelet[755]: E1105 09:40:01.892304 755 kubelet.go:2236] node "master01" not found
Nov 5 09:40:01 master01 kubelet[755]: E1105 09:40:01.928937 755 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:47: Failed to list *v1.Pod: Get https://x.x.x.x:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dkubernetserver&limit=500&resourceVersion=0: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
Nov 5 09:40:01 master01 kubelet[755]: E1105 09:40:01.992427 755 kubelet.go:2236] node "master01" not found
EDIT 2 - 1. Now the real question is - if regenerating certs do not enable trust to itself as a CA, how do you fix this problem? 2. Is this a problem that is well known?