I'm trying to setup an SSL connection from wildfly to CloudSQL Postgres DB.
After having downloaded ssl certs from CloudSQL (server-ca.pem, client-cert.pem and client-key.pem), I created keystore and trustore in the following way:
keytool -import -alias server -file server-ca.pem -keystore truststore.jks -storepass password
openssl pkcs12 -export -in client-cert.pem -inkey client-key.pem -out client.p12 -name client
keytool -importkeystore -deststorepass password -destkeystore keystore.jks -srckeystore client.p12 -srcstoretype PKCS12 -srcstorepass password -alias client
Then I've changed JAVA_OPTS env variable, to provide the keystore created:
export JAVA_OPTS="-server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Djavax.net.ssl.keyStore=keystore.jks -Djavax.net.ssl.keyStorePassword=password -Djavax.net.ssl.trustStore=truststore.jks -Djavax.net.ssl.trustStorePassword=password"
Then I've changed postgres datasource in standalone.xml:
jdbc:postgresql://XX.XX.XX.XX:5432/db?sslmode=require
At wildfly startup, I got the following error:
org.postgresql.util.PSQLException: FATAL: connection requires a valid client certificate
Any idea?
Cloud SQL creates a server certificate automatically when you create your instance. As long as the server certificate is valid, the certificate has an expiration date; after that date, it is no longer valid, and clients are not able to establish a secure connection to your instance using that certificate.
https://cloud.google.com/sql/docs/postgres/configure-ssl-instance
Related
I am testing a Debian 10 Linux server with:
Apache2 (2.4)
Postfix
Dovecot
Ports are now opened: 25, 110, 143, 465, 587, 993, 995
Previously, the postfix & dovecot are using self-signed cert.
Postfix
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
Dovecot
ssl_cert = </etc/dovecot/private/dovecot.pem
ssl_key = </etc/dovecot/private/dovecot.key
Then, I would like to update with Let's Encrypt cert.
sudo certbot certonly --apache -d example.com -d www.example.com -d mail.example.com
Postfix
smtpd_tls_cert_file=/etc/letsencrypt/live/example.com/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/example.com/privkey.key
Dovecot
ssl_cert = </etc/letsencrypt/live/example.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/example.com/privkey.key
For the same certificate, it is running fine with Apache2.
Problem
openssl s_client -crlf -connect 127.0.0.1:465
Error: no peer certificate available
openssl s_client -crlf -connect mail.example.com:465
no response, halt!
hostname -f (run locally)
mail.example.com
What is missed? Is it related to DNS? DNS server (bind9) is also located in this testing machine.
Dears,
I do not have any idea what is wrong in my configuration. When I want to start Kafka service I've got an error:
[2020-11-30 08:52:33,502] DEBUG Created SSL context with keystore SecurityStore(path=/etc/pki/CA/certs/node1.corp.jks, modificationTime=Mon Nov 30 08:40:08 CET 2020), truststore SecurityStore(path=/etc/pki/ca-trust/extracted/java/cacerts, modificationTime=Wed Nov 25 09:20:22 CET 2020), provider SunJSSE. (org.apache.kafka.common.security.ssl.SslEngineBuilder)
[2020-11-30 08:52:33,702] ERROR [KafkaServer id=1] Fatal error during KafkaServer startup. Prepare to shutdown (kafka.server.KafkaServer)
org.apache.kafka.common.KafkaException: org.apache.kafka.common.config.ConfigException: Invalid value javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target for configuration A client SSLEngine created with the provided settings can't connect to a server SSLEngine created with those settings.
at org.apache.kafka.common.network.SaslChannelBuilder.configure(SaslChannelBuilder.java:158)
at org.apache.kafka.common.network.ChannelBuilders.create(ChannelBuilders.java:146)
at org.apache.kafka.common.network.ChannelBuilders.serverChannelBuilder(ChannelBuilders.java:85)
at kafka.network.Processor.<init>(SocketServer.scala:753)
at kafka.network.SocketServer.newProcessor(SocketServer.scala:394)
at kafka.network.SocketServer.$anonfun$addDataPlaneProcessors$1(SocketServer.scala:279)
at scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:158)
at kafka.network.SocketServer.addDataPlaneProcessors(SocketServer.scala:278)
at kafka.network.SocketServer.$anonfun$createDataPlaneAcceptorsAndProcessors$1(SocketServer.scala:241)
at kafka.network.SocketServer.$anonfun$createDataPlaneAcceptorsAndProcessors$1$adapted(SocketServer.scala:238)
at scala.collection.mutable.ResizableArray.foreach(ResizableArray.scala:62)
at scala.collection.mutable.ResizableArray.foreach$(ResizableArray.scala:55)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:49)
at kafka.network.SocketServer.createDataPlaneAcceptorsAndProcessors(SocketServer.scala:238)
at kafka.network.SocketServer.startup(SocketServer.scala:121)
at kafka.server.KafkaServer.startup(KafkaServer.scala:263)
at kafka.server.KafkaServerStartable.startup(KafkaServerStartable.scala:44)
at kafka.Kafka$.main(Kafka.scala:84)
at kafka.Kafka.main(Kafka.scala)
Caused by: org.apache.kafka.common.config.ConfigException: Invalid value javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target for configuration A client SSLEngine created with the provided settings can't connect to a server SSLEngine created with those settings.
at org.apache.kafka.common.security.ssl.SslFactory.configure(SslFactory.java:100)
at org.apache.kafka.common.network.SaslChannelBuilder.configure(SaslChannelBuilder.java:154)
... 18 more
I've got three files from other Team: CAroot certificate (PEM *.crt), Private key (PEM private *.pem) and certificate (PEM *.crt) for each node.
The keystore was create like this:
keytool -noprompt -keystore node1.corp.jks -alias rootca -import -file testcorp.crt -storepass kafka123
Next key was imported to truststore and keystore like this:
openssl pkcs12 -export -in node1.crt -inkey node1.pem -out node1.p12 -password pass:kafka123
keytool -noprompt -importkeystore -srckeystore node1.p12 -srcstoretype PKCS12 -destkeystore node1.corp.jks -dname "CN=node1, OU=ITC, O=ITC, L=CITY, ST=SOME, C=PL" -deststoretype JKS -storepass kafka123 -keypass kafka123 -keyalg RSA -validity 365
Kafka configuration file looks like:
broker.id=1
delete.topic.enable=true
auto.create.topics.enable=true
listeners=SASL_SSL://:9093
advertised_listeners=SASL_SSL://192.168.1.101:9093
ssl.endpoint.identification.algorithm=
sasl.enabled.mechanisms=SCRAM-SHA-512
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512
security.inter.broker.protocol=SASL_SSL
authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer
allow.everyone.if.no.acl.found=true
ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1
ssl.secure.random.implementation=SHA1PRNG
super.users=User:admin
ssl.client.auth=none
ssl.keystore.location=/etc/pki/CA/certs/node1.corp.jks
ssl.keystore.password=kafka123
ssl.key.password=kafka123
ssl.truststore.location=/etc/pki/ca-trust/extracted/java/cacerts
ssl.truststore.password=kafka123
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
offsets.topic.replication.factor=3
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=3
log.dirs=/kafka_data
num.partitions=1
num.recovery.threads.per.data.dir=1
log.flush.interval.messages=10000
log.flush.interval.ms=1000
log.retention.hours=168
log.retention.bytes=1073741824
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
zookeeper.connect=192.168.1.101:2181,192.168.1.102:2181,192.168.1.103:2181
I do not have any idea what is wrong. Did you have similar problems? Do you have any idea what is wrong?
Best Regards,
Dan
Something changed in our DNS serwer. Recreation of keystores solved problems.
I'm trying to install kubernetes with kubelet 1.4.5 on CoreOS beta (1192.2.0).
I'm using a slightly modified version of the controller and worker install scripts from https://github.com/coreos/coreos-kubernetes/tree/master/multi-node/generic
so in general I created the licenses on Gentoo Linux using the following bash script:
#!/bin/bash
export MASTER_HOST=coreos-2.tux-in.com
export K8S_SERVICE_IP=10.3.0.1
export WORKER_IP=10.79.218.3
export WORKER_FQDN=coreos-3.tux-in.com
openssl genrsa -out ca-key.pem 2048
openssl req -x509 -new -nodes -key ca-key.pem -days 10000 -out ca.pem -subj "/CN=kube-ca"
openssl genrsa -out apiserver-key.pem 2048
openssl req -new -key apiserver-key.pem -out apiserver.csr -subj "/CN=kube-apiserver" -config openssl.cnf
openssl x509 -req -in apiserver.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out apiserver.pem -days 365 -extensions v3_req -extfile openssl.cnf
openssl genrsa -out ${WORKER_FQDN}-worker-key.pem 2048
openssl req -new -key ${WORKER_FQDN}-worker-key.pem -out ${WORKER_FQDN}-worker.csr -subj "/CN=${WORKER_FQDN}" -config worker-openssl.cnf
openssl x509 -req -in ${WORKER_FQDN}-worker.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out ${WORKER_FQDN}-worker.pem -days 365 -extensions v3_req -extfile worker-openssl.cnf
openssl genrsa -out admin-key.pem 2048
openssl req -new -key admin-key.pem -out admin.csr -subj "/CN=kube-admin"
openssl x509 -req -in admin.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out admin.pem -days 365
echo done
and this is openssl.cnf
[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = #alt_names
[alt_names]
DNS.1 = coreos-2.tux-in.com
DNS.2 = coreos-3.tux-in.com
IP.1 = 10.3.0.1
IP.2 = 10.79.218.2
IP.3 = 10.79.218.3
and this is my worker-openssl.cnf
[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = #alt_names
[alt_names]
IP.1 = 10.79.218.3
DNS.1 = coreos-3.tux-in.com
My controller machine is coreos-2.tux-in.com which resolves to the lan ip 10.79.218.2
my worker machine is coreos-3.tux-in.com which resolves to lan ip 10.79.218.3
it created the licenses just fine. but when I use them and install the controller script on the main machine, i see that when I run journalctl -xef -u kubelet and I noticed the following messages:
Nov 08 21:24:06 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:06.805868 2018 event.go:208] Unable to write event: 'x509: certificate signed by unknown authority' (may retry after sleeping)
Nov 08 21:24:06 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:06.950827 2018 reflector.go:203] pkg/kubelet/kubelet.go:384: Failed to list *api.Service: Get https://coreos-2.tux-in.com:443/api/v1/services?resourceVersion=0: x509: certificate signed by unknown authority
Nov 08 21:24:07 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:07.461042 2018 reflector.go:203] pkg/kubelet/config/apiserver.go:43: Failed to list *api.Pod: Get https://coreos-2.tux-in.com:443/api/v1/pods?fieldSelector=spec.nodeName%3D10.79.218.2&resourceVersion=0: x509: certificate signed by unknown authority
Nov 08 21:24:07 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:07.461340 2018 reflector.go:203] pkg/kubelet/kubelet.go:403: Failed to list *api.Node: Get https://coreos-2.tux-in.com:443/api/v1/nodes?fieldSelector=metadata.name%3D10.79.218.2&resourceVersion=0: x509: certificate signed by unknown authority
Nov 08 21:24:08 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:08.024366 2018 reflector.go:203] pkg/kubelet/kubelet.go:384: Failed to list *api.Service: Get https://coreos-2.tux-in.com:443/api/v1/services?resourceVersion=0: x509: certificate signed by unknown authority
Nov 08 21:24:08 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:08.171170 2018 eviction_manager.go:162] eviction manager: unexpected err: failed GetNode: node '10.79.218.2' not found
Nov 08 21:24:08 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:08.543619 2018 reflector.go:203] pkg/kubelet/kubelet.go:403: Failed to list *api.Node: Get https://coreos-2.tux-in.com:443/api/v1/nodes?fieldSelector=metadata.name%3D10.79.218.2&resourceVersion=0: x509: certificate signed by unknown authority
Nov 08 21:24:08 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:08.543926 2018 reflector.go:203] pkg/kubelet/config/apiserver.go:43: Failed to list *api.Pod: Get https://coreos-2.tux-in.com:443/api/v1/pods?fieldSelector=spec.nodeName%3D10.79.218.2&resourceVersion=0: x509: certificate signed by unknown authority
The kubelet documentation says that the --tls-cert-file flag needs the CA be concatenated after the certificate. In you case it is the apiserver.pem:
--tls-cert-file File containing x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory passed to --cert-dir.
If I read you certificate generation correctly, the apiserver.pem doesn't contain the root ca.
0. if your issue is :
: Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "x509: invalid signature: parent certificate cannot sign this kind of certificate"
1. look at your ca.crt
openssl x509 -noout -text -in ca.crt, you will find below info :
X509v3 Basic Constraints:
CA:FLASE
X509v3 Basic Constraints means :
"Basic Constraints" identifies if the subject of certificates is a CA who is allowed to issue child certificates. For a certificate that can be used to sign certificates, the info is in some sense duplicated: X509v3 Basic Constraints: CA: TRUE --- Can sign certificates.
you should modify it to CA:TRUE through vi openssl.conf
[ v3_ca ]
basicConstraints = CA:true
Regenerate your crts.
I'm using kubelet with rkt on CoreOS 1192.2.0.
This is the unit i use to start kubelet on the worker:
[Unit]
Description=Kubelet via Hyperkube ACI
Requires=k8s-assets.target
After=k8s-assets.target
[Service]
EnvironmentFile=/etc/proxy.env
Environment="RKT_OPTS=--volume=resolv,kind=host,source=/etc/resolv.conf --mount volume=resolv,target=/etc/resolv.conf --volume var-log,kind=host,source=/var/log --mount volume=var-log,target=/var/log"
Environment=KUBELET_VERSION=v1.4.0_coreos.0
ExecStartPre=/usr/bin/mkdir -p /etc/kubernetes/manifests
ExecStart=/usr/lib/coreos/kubelet-wrapper \
--api-servers=https://10.203.69.108 \
--register-node=true \
--allow-privileged=true \
--config=/etc/kubernetes/manifests \
--hostname-override=node2.my.domain \
--cluster_dns=10.3.0.10 \
--cluster_domain=cluster.local \
--kubeconfig=/etc/kubernetes/worker-kubeconfig.yaml \
--tls-cert-file=/etc/kubernetes/ssl/worker.pem \
--tls-private-key-file=/etc/kubernetes/ssl/worker-key.pem
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
What is important is
--api-servers that must point to the IP address of the master
--tls-cert-file that must point to the worker certificate public key
--tls-private-key-file that must point to the worker certificate private key
--kubeconfig that must point to a valid kubeconfig file
Here my kubeconfig file (it contain the path to the CA that have signed the certificates):
apiVersion: v1
kind: Config
clusters:
- name: local
cluster:
certificate-authority: /etc/kubernetes/ssl/ca.pem
users:
- name: kubelet
user:
client-certificate: /etc/kubernetes/ssl/worker.pem
client-key: /etc/kubernetes/ssl/worker-key.pem
contexts:
- context:
cluster: local
user: kubelet
name: kubelet-context
current-context: kubelet-context
Your OpenSSL certificates are "self-signed":
openssl genrsa -out ca-key.pem 2048
openssl req -x509 -new -nodes -key ca-key.pem -days 10000 -out ca.pem -subj "/CN=kube-ca"
That is to say, you are signing them instead of a trusted certificate authority. It should be completely fine and safe, as long as you keep the private keys safe.
If you want it to be signed by a certificate authority, you will need to generate a CSR (certificate signing request).
https://www.digitalocean.com/community/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs
in general the solution was to create another etcd2 port that attaches to loopback device of each machine and works on http instead of https. more information at calico-policy-controller requests etcd2 certificates of a different coreos server
I'm using pyOpenSSL to create a X509 certifcate. I need to import this certificate into a Java JKS keystore to make it available to my Java application. This is working fine as long as I don't add a subjectAltName extension to the certificate. If the certificate has an alternative subject set, import into the JKS keystore fails:
root#51561a8a1e01:~# /opt/oracle/java/jdk64-1.8.0_92/bin/keytool -keystore keystore -storepass changeit -noprompt -importcert -alias example -file certificate.crt -v
keytool error: java.lang.Exception: Input not an X.509 certificate
java.lang.Exception: Input not an X.509 certificate
at sun.security.tools.keytool.Main.doCommands(Main.java:1009)655)
at sun.security.tools.keytool.Main.main(Main.java:336)
root#51561a8a1e01:~#
If I print this certificate using OpenSSL on the command line, I get this output:
root#51561a8a1e01:~# openssl x509 -in certificate.crt -text -noout
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 0 (0x0)
Signature Algorithm: sha256WithRSAEncryption
Issuer: OU=example.com, CN=my-server.example.com, O=example.com
Validity
Not Before: Aug 26 12:03:03 2016 GMT
Not After : Aug 25 12:03:03 2021 GMT
Subject: OU=example.com, CN=my-server.example.com, O=example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:cc:a7:53:5a:38:...:11:2f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:localhost
Signature Algorithm: sha256WithRSAEncryption
ab:51:12:fb:a6:a6:...:0d:4b
That is the certificate is obviously valid. And according to oracle's documentation the Java 8 keytool should support the SubjectAlternativeName extension.
When I tried to generate everything with keytool itself - which seems to work - I noticed that the certificate generated by keytool has a second extension X509v3 Subject Key Identifier:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1510484556 (0x5a082a4c)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=example.com, OU=example.com, CN=my-server.example.com
Validity
Not Before: Aug 26 12:52:43 2016 GMT
Not After : Nov 24 12:52:43 2016 GMT
Subject: O=example.com, OU=example.com, CN=my-server.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:99:b6:b1:11:a6:...:7b:39
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:localhost
X509v3 Subject Key Identifier:
66:75:AD:7A:A5:19:AB:43:DE:55:E4:A7:4F:C2:3D:53:55:49:CE:48
Signature Algorithm: sha256WithRSAEncryption
50:7c:fe:c8:5d:1b:...:da:27
Do I need to add this extension to my certificate using pyOpenSSL as well. But what would be the correct value?!
Well, just after writing down everything for this question I noticed that there is a second difference between the certificate generated with pyOpenSSL and the keytool one. The keytool certificate states Version: 3 (0x2) while the other one says Version: 1 (0x0).
I'm not too much into the X509 specs but as the extensions are all prefixed with X509v3 I'd guess that extension support is not available for version 1 certificates.
And after adapting my python code to set the version to 3 (actually 2 as version is 0 based), import into keytool works as expected:
_req = OpenSSL.crypto.X509Req()
_req.set_version(2)
...
This is what I did exactly for establishing SSL connection.
1 Use openssl to generate a client and a server key (c.pem, s.pem)
2 Use openssl to generate a client key request and server key request
3 Get CA to sign both req and get the certs: c.cer , s.cer
4 concatenate c.pem and c.cer and get client.pem, similarly, get server.pem
Now start the server:
mongod --sslMode requireSSL --sslPEMKeyFile server.pem -sslCAFile caroot.cer
start the client:
mongo --ssl --sslCAFile caroot.cer --sslPEMKeyFile client.pem
And now I am getting the error:
E NETWORK SSL peer certificate validation failed:certificate not trusted
Any thoughts on why this doesn't work?