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.
Related
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
I am trying to run a single kafka server using SASL and GSSAPI with plaintext but getting below error.
[2018-10-03 16:08:54,220] ERROR [Controller id=0, targetBrokerId=0]
Connection to node 0 failed authentication due to: An error:
(java.security.PrivilegedActionException:
javax.security.sasl.SaslException: GSS initiate failed [Caused by
GSSException: No valid credentials provided]) occurred when evaluating
SASL token received from the Kafka Broker. Kafka Client will go to
AUTHENTICATION_FAILED state. (org.apache.kafka.clients.NetworkClient)
in server.properties changes are:
listeners=SASL_PLAINTEXT://kafka.example.com:9095
security.inter.broker.protocol=SASL_PLAINTEXT
sasl.mechanism.inter.broker.protocol=GSSAPI
advertised.listeners=SASL_PLAINTEXT://kafka.example.com:9095
sasl.enabled.mechanism=GSSAPI
sasl.kerberos.service.name=HTTP
Here is my jaas config:
KafkaServer {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
useTicketCache=true
storeKey=true
keyTab="/home/kafka/kafka_server.keytab"
principal="HTTP/kafka.example.com#UNIX.EXAMPLE.COM";
};
Any leads on how to resolve this?
First of all,
Either use KeyTab (useKeyTab=true) or use TicketCache (useTicketCache=true). Do not use both at once. This may lead to conflicts.
If you have your own Kerb, create a principle for kafka
sudo /usr/sbin/kadmin.local -q 'addprinc -randkey kafka/{hostname}#{REALM}'
sudo /usr/sbin/kadmin.local -q "ktadd -k /etc/security/keytabs/{keytabname}.keytab kafka/{hostname}#{REALM}"
use
sasl.kerberos.service.name="kafka"
Set JVM parameters
export KAFKA_OPTS="-Djava.security.auth.login.config=/path/to/jaas.conf
-Djava.security.krb5.conf=/etc/krb5.conf -Dsun.security.krb5.debug=true"
Hope this would help.
I am facing a weird problem where my mirror-maker is able to mirror the topic name in the destination cluster but I am seeing no messages when I try to consume messages from it. Below is my configuration file –
Kafka version : kafka_10.0.1
All Certs /Keys are my organization issued certificate so no Error for SSL
Source Cluster :
==============
Zookeeeper Properties
dataDir=/home/kafka/zookeeper
clientPort=2181
maxClientCnxns=3
Server Properties
broker.id=1
listeners= SSL://123.456.789.110:9092
advertised.listeners=SSL://123.456.789.110:9092
security.inter.broker.protocol=SSL
num.network.threads=3
num.io.threads=8
auto.create.topics.enable=true
ssl.client.auth=none
ssl.keystore.location=/etc/keys/keystore
ssl.keystore.password=test1234
ssl.truststore.location=/etc/CApath/trustedstore
ssl.truststore.password=test1234
ssl.enabled.protocols=TLSv1.2
log.dirs=/home/kafka/kafka-logs
zookeeper.connect=123.456.789.110:2181
Kafka Up and Running . Log persistently logging in Source Cluster
Target Cluster :
================
Zookeeeper Properties
dataDir=/home/kafka/zookeeper
clientPort=2181
maxClientCnxns=3
Server Properties
broker.id=1
listeners= SSL://234.456.789.110:9092
advertised.listeners=SSL://sl73easapd04.visa.com:9092
security.inter.broker.protocol=SSL
num.network.threads=3
num.io.threads=8
ssl.client.auth=none
ssl.keystore.location=/etc/keys/keystore
ssl.keystore.password=test1234
ssl.truststore.location=/etc/CApath/trustedstore
ssl.truststore.password=test1234
ssl.enabled.protocols=TLSv1.2
ssl.keystore.type = JKS
ssl.truststore.type = JKS
log.dirs=/data/visingh/kafka/kafka-logs
num.partitions=1
num.recovery.threads.per.data.dir=1
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
zookeeper.connect=234.456.789.110:2181
zookeeper.connection.timeout.ms=6000
mm_consumer.properties :
bootstrap.servers=123.456.789.110:9092
exclude.internal.topics = true
auto.offset.reset=earliest
security.protocol = SSL
ssl.truststore.location=/etc/CApath/trustedstore
ssl.truststore.password=Test1234
ssl.enabled.protocols= TLSv1.2
ssl.keystore.location=/etc/keys/keystore
ssl.keystore.password=Test1234
ssl.truststore.type=JKS
ssl.keystore.type=JKS
zookeeper.connection.timeout.ms=6000
group.id=test-consumer-group
client.id=mirror_maker_consumer
consumer.timeout.ms=50000
mm_producer.properties :
bootstrap.servers=234.456.789.110:9092
acks=1
batch.size=100
security.protocol = SSL
ssl.truststore.location=/etc/CApath/trustedstore
ssl.truststore.password=Test1234
ssl.enabled.protocols=TLSv1.2
ssl.keystore.location=/etc/keys/keystore
ssl.keystore.password=Test1234
ssl.truststore.type=JKS
ssl.keystore.type=JKS
compression.type=gzip
I then started Mirror-Maker with the following command,This command run fines and topic APP-logging created in Target cluster but not logs on target Cluster.
bin/kafka-run-class.sh kafka.tools.MirrorMaker --new.consumer --consumer.config config/mm_consumer.properties --producer.config config/mm_producer.properties --whitelist *
kafka MirroMaker Started but no logs on target Cluster.
I executed started another mirror maker command using topic name with below command ,This command fails on target hostCluster
/bin/kafka-mirror-maker.sh --new.consumer --consumer.config config/mm_consumer.properties --producer.config config/mm_producer.properties --whitelist APP-logging
[2018-06-22 03:59:27,536] FATAL [mirrormaker-thread-0] Mirror maker thread
failure due to (kafka.tools.MirrorMaker$MirrorMakerThread)
java.lang.IllegalArgumentException: Invalid timestamp -1
at org.apache.kafka.clients.producer.ProducerRecord.<init> (ProducerRecord.java:60)
at kafka.tools.MirrorMaker$defaultMirrorMakerMessageHandler$.handle(MirrorMaker.scala:678)
at kafka.tools.MirrorMaker$MirrorMakerThread.run(MirrorMaker.scala:414)
[2018-06-22 03:59:27,563] FATAL [mirrormaker-thread-0] Mirror maker thread exited abnormally, stopping the whole mirror maker. (kafka.tools.MirrorMaker$MirrorMakerThread)
Also run the ".*" including the quotes instead of just *.
bin/kafka-run-class.sh kafka.tools.MirrorMaker --new.consumer --consumer.config config/mm_consumer.properties --producer.config config/mm_producer.properties --whitelist ".*"
[2018-06-22 04:22:01,647] FATAL [mirrormaker-thread-0] Mirror maker thread failure due to (kafka.tools.MirrorMaker$MirrorMakerThread)
java.lang.IllegalArgumentException: Invalid timestamp -1
at org.apache.kafka.clients.producer.ProducerRecord.<init>(ProducerRecord.java:60)
at kafka.tools.MirrorMaker$defaultMirrorMakerMessageHandler$.handle(MirrorMaker.scala:678)
at kafka.tools.MirrorMaker$MirrorMakerThread.run(MirrorMaker.scala:414)
[2018-06-22 04:22:01,674] FATAL [mirrormaker-thread-0] Mirror maker thread exited abnormally, stopping the whole mirror maker. (kafka.tools.MirrorMaker$MirrorMakerThread)
Am I missing something?
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)
...