I want to create connection to a server with https connection, I want to use self signed ssl key, but when open the connection with Connector.open(url) the following exception is eccured :
javax.microedition.pki.CertificateException: Certificate was issued by an unrecognized entity
com.sun.midp.pki.X509Certificate.verifyChain(), bci=6
- com.sun.midp.ssl.Handshake.parseChain(), bci=106
- com.sun.midp.ssl.Handshake.rcvCert(), bci=92
- com.sun.midp.ssl.Handshake.doHandShake(), bci=77
- com.sun.midp.ssl.SSLStreamConnection.(), bci=161
- com.sun.midp.io.j2me.https.Protocol.connect(), bci=215
- com.sun.midp.io.j2me.http.Protocol.streamConnect(), bci=164
- com.sun.midp.io.j2me.http.Protocol.startRequest(), bci=7
- com.sun.midp.io.j2me.http.Protocol.sendRequest(), bci=33
- com.sun.midp.io.j2me.http.Protocol.sendRequest(), bci=3
- com.sun.midp.io.j2me.https.Protocol.getSecurityInfo(), bci=5
- main.MainMidlet.commandAction(MainMidlet.java:66)
- javax.microedition.lcdui.Display$ChameleonTunnel.callScreenListener(), bci=39
- com.sun.midp.chameleon.layers.SoftButtonLayer.processCommand(), bci=62
- com.sun.midp.chameleon.layers.SoftButtonLayer.soft1(), bci=27
- com.sun.midp.chameleon.layers.SoftButtonLayer.keyInput(), bci=48
- com.sun.midp.chameleon.CWindow.keyInput(), bci=30
- javax.microedition.lcdui.Display$DisplayEventConsumerImpl.handleKeyEvent(), bci=43
- com.sun.midp.lcdui.DisplayEventListener.process(), bci=252
- com.sun.midp.events.EventQueue.run(), bci=130
- java.lang.Thread.run(), bci=5
can any body help me with a sample code to solve problem.
The server's self-signed certificate isn't trusted by the client. Either get it signed by a CA or exported into the client's truststore.
Related
I have a problem with solr 8_4 SSL.
I can't connect with https://localhost:8983 ,but http://localhost:8983 is worked.
I am use https://lucene.apache.org/solr/guide/8_4/enabling-ssl.html for configuring SSL with self sign certificate.
Setting made are :
SOLR_SSL_ENABLED=true
SOLR_SSL_KEY_STORE=/opt/solr/server/etc/solr-ssl.keystore.jks SOLR_SSL_KEY_STORE_PASSWORD=secret SOLR_SSL_TRUST_STORE=/opt/solr/server/etc/solr-ssl.keystore.jks SOLR_SSL_TRUST_STORE_PASSWORD=secret
SOLR_SSL_NEED_CLIENT_AUTH=false
SOLR_SSL_WANT_CLIENT_AUTH=false
SOLR_SSL_CLIENT_HOSTNAME_VERIFICATION=false
SOLR_SSL_KEY_STORE_TYPE=JKS
SOLR_SSL_CHECK_PEER_NAME=true
I am getting below certification error while i am trying to call any API https://:8243/ from a react based frontend application. I have defined my rest API in wso2 EI 6.3. I am not using wso2 APIM.
What i did to resolve this issue:
1. I created a new self signed certificate and created a new key store. Updated carbon.xml, axis2.xml file. Restart the server. I am able to see my certificate in wso2 Ei GUI.
2. I accepted the certificate in browser.
But still i am not able to get rid of this error.
Is this error coming due to self signed certificate? If i will be using any CA signed certificate then this issue will not be there?
Any help or pointer is highly appreciated.
[2020-04-07 08:54:48,841] [-1] [] [HTTPS-Listener I/O dispatcher-2] ERROR {org.apache.synapse.transport.passthru.SourceHandler} - I/O error: Received fatal alert: certificate_unknown
javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1647)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1615)
at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1781)
at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1070)
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:896)
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:766)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doUnwrap(SSLIOSession.java:245)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:280)
at org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:410)
at org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:119)
at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:159)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:338)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:316)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:277)
at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:105)
at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:586)
at java.lang.Thread.run(Thread.java:748)
BR//
Vipin Nirwal
I was able to resolve this issue. I followed the below steps.
I created a self CA first. Then created a certificate signed by my own CA. Import the root certificate of my CA into the browser As this CA needs to be trusted by browser.
After this update carbon.xml, files inside axis2 directory and catalina-server.xml file with proper jks file and password for keystores.
Restarted the server.
You can try to debug it yourself by enabling SSL debug logs in the EI server. In the SSL logs, you can check whether the client certificate and the server certificate is matching. Have a look at the following blog.
https://medium.com/#nipunadilhara/enabling-ssl-debug-logs-for-wso2-products-30833d5de88e
I'm currently configuring Apache Kafka with SSL authentication and am coming across an error when starting the service. It appears that the broker starts up correctly(leader election etc seems to occur), but as soon as any cluster operations begin to take place, I get the error below continually in the logs.
[2019-05-16 11:04:00,351] INFO [Controller id=1, targetBrokerId=1] Failed authentication with XXXX/YYYY (SSL handshake failed) (org.apache.kafka.common.network.Selector)
[2019-05-16 11:04:00,351] DEBUG [Controller id=1, targetBrokerId=1] Node 1 disconnected. (org.apache.kafka.clients.NetworkClient)
[2019-05-16 11:04:00,351] DEBUG An authentication error occurred in broker-to-broker communication. (org.apache.kafka.clients.ManualMetadataUpdater)
org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed
Caused by: javax.net.ssl.SSLProtocolException: Handshake message sequence violation, 2
Tried recreating the key and trust stores, tried dropping SSL from the inter broker listener(this results in an ANONYMOUS principal that I don't want to grant access to any resource).
To explain my configuration:
Running Kafka 2.2 using the SSL principal builder
I have 3 listeners setup - one on a public interface, and two on private interfaces(one for inter-broker comms and one for internal consumers)
SSL is enabled on all 3 listeners
Each listener is tied to it's own key and trust stores(as I need to be able to present different certificates for the internal addresses, as well as being able to trust different signing CA's), and SSL key password is provided for each key/keystore.
Certificates were created using a locally generated key, local CSR generated then signed by a CA running on CFSSL multiroot.
Keystores were then created using the key(same password), signed certificate and CA certificate imported.
Truststore was created and certificate issuing CA(s) added here.
#Kafka Server Properties Configuration
#Broker and listener configuration
broker.id=1
listeners=egress://address1:9093,inter://address1:9094,ingest://address2:9092
advertised.listeners=egress://address1:9093,inter://address1:9094,ingest://address2:9092
listener.security.protocol.map=egress:SSL,inter:SSL,ingest:SSL
inter.broker.listener.name=inter
##
#Listener Trust and Keystore Configurations
#egress configuration
listener.name.egress.ssl.keystore.type=JKS
listener.name.egress.ssl.keystore.location=/data/kafka/pki/egress-keystore.jks
listener.name.egress.ssl.keystore.password=<redacted>
listener.name.egress.ssl.truststore.type=JKS
listener.name.egress.ssl.truststore.location=/data/kafka/pki/egress-truststore.jks
listener.name.egress.ssl.truststore.password=<redacted>
listener.name.egress.ssl.key.password=<redacted>
listener.name.egress.ssl.client.auth=required
listener.name.egress.ssl.principal.mapping.rules=RULE:^.*[Oo][Uu]=([a-zA-Z0-9.-]*).*$/$1/L,DEFAULT
##
#inter configuration
listener.name.inter.ssl.keystore.type=JKS
listener.name.inter.ssl.keystore.location=/data/kafka/pki/inter-keystore.jks
listener.name.inter.ssl.keystore.password=<redacted>
listener.name.inter.ssl.truststore.type=JKS
listener.name.inter.ssl.truststore.location=/data/kafka/pki/inter-truststore.jks
listener.name.inter.ssl.truststore.password=<redacted>
listener.name.inter.ssl.key.password=<redacted>
listener.name.inter.ssl.client.auth=requested
listener.name.inter.ssl.principal.mapping.rules=RULE:^.*[Oo][Uu]=([a-zA-Z0-9.-]*).*$/$1/L,DEFAULT
##
#ingest configuration
listener.name.ingest.ssl.keystore.type=JKS
listener.name.ingest.ssl.keystore.location=/data/kafka/pki/ingest-keystore.jks
listener.name.ingest.ssl.keystore.password=<redacted>
listener.name.ingest.ssl.truststore.type=JKS
listener.name.ingest.ssl.truststore.location=/data/kafka/pki/ingest-truststore.jks
listener.name.ingest.ssl.truststore.password=<redacted>
listener.name.ingest.ssl.key.password=<redacted>
listener.name.ingest.ssl.client.auth=required
listener.name.ingest.ssl.principal.mapping.rules=RULE:^.*[Oo][Uu]=([a-zA-Z0-9.-]*).*$/$1/L,DEFAULT
##
#Generic SSL Configuration
ssl.keystore.type=JKS
ssl.keystore.location=/data/kafka/pki/inter-keystore.jks
ssl.keystore.password=<redacted>
ssl.truststore.type=JKS
ssl.truststore.location=/data/kafka/pki/inter-truststore.jks
ssl.truststore.password=<redacted>
ssl.key.password=<redacted>
ssl.client.auth=requested
ssl.principal.mapping.rules=RULE:^.*[Oo][Uu]=([a-zA-Z0-9.-]*).*$/$1/L,DEFAULT
ssl.enabled.protocols=TLSv1.2
authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer
allow.everyone.if.no.acl.found=false
super.users=User:<redacted>
##
#General configuration
auto.create.topics.enable=False
delete.topic.enable=True
log.dir=/var/log/kafka
log.retention.hours=24
log.cleaner.enable=True
log.cleanup.policy=delete
log.retention.check.interval.ms=3600000
min.insync.replicas=2
replication.factor=3
default.replication.factor=3
num.partitions=50
offsets.topic.num.partitions=50
offsets.topic.replication.factor=3
transaction.state.log.min.isr=2
transaction.state.log.num.partitions=50
num.replica.fetchers=4
auto.leader.rebalance.enable=True
leader.imbalance.check.interval.seconds=60
transactional.id.expiration.ms=10000
unclean.leader.election.enable=False
zookeeper.connect=zookeeper:2180
zookeeper.session.timeout.ms=100
controlled.shutdown.enable=True
broker.rack=rack1
Did you inserts the certificates to the keystores in the order you described? It could be important to first set the ca, then the certificate signed by the ca to get the chain of trust correctly.
We've been following the guide for automatic sidecar injection in istio-0.5.0 on kubernetes 1.9.2, but have so far been unsuccessful due to certificate issues on the api-server.
When pods are created, the webhook is called, but the api-server rejects the certficate presented by istio-sidecar-injector/inject, stating:
W0205 09:15:27.389473 1 admission.go:257] Failed calling webhook, failing open sidecar-injector.istio.io: failed calling admission webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-system.svc:443/inject: x509: certificate signed by unknown authority
E0205 09:15:27.389501 1 admission.go:258] failed calling admission webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-system.svc:443/inject: x509: certificate signed by unknown authority
Our API server has been configured with the following flags:
- --allow-privileged=true
- --kubelet-client-certificate=/etc/kubernetes/pki/admin.pem
- --kubelet-client-key=/etc/kubernetes/pki/admin-key.pem
- --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
- --tls-ca-file=/etc/kubernetes/pki/ca.pem
- --tls-cert-file=/etc/kubernetes/pki/kube-apiserver-server.pem
- --tls-private-key-file=/etc/kubernetes/pki/kube-apiserver-server-key.pem
- --secure-port=6443
- --enable-bootstrap-token-auth
- --storage-backend=etcd3
- --service-cluster-ip-range=10.254.0.0/16
- --service-account-key-file=/etc/kubernetes/pki/sa.pub
- --client-ca-file=/etc/kubernetes/pki/ca.pem
- --insecure-port=8080
- --insecure-bind-address=127.0.0.1
- --admissioncontrol=MutatingAdmissionWebhook,Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds
- --authorization-mode=RBAC
- --oidc-issuer-url=https://sts.windows.net/[...removed...]/
- --oidc-client-id=spn:[...removed...]
- --oidc-username-claim=upn
- --oidc-groups-claim=groups
- --v=0
- --advertise-address=10.1.1.200
- --etcd-servers=http://etcd-0:2379,http://etcd-1:2379,http://etcd-2:2379
The certificate has been signed by the ca.pem file, which we have given to the api-server via the --tls-ca-file flag, but still no cigar.
Any ideas out there on how we can get the kubernetes API admission controller to trust the certificate presented by the sidecar-injector?
I am making both server and client for an application, using the ACE library with OpenSSL. I am trying to get mutual authentication to work, o the server will only accept connections from trusted clients.
I have generated a CA key and cert, and used it to sign a server cert and a client cert (each with their own keys also). I seem to be loading the trusted store correctly, but I keep getting the error "peer did not return a certificate" during handshake.
Server side code:
ACE_SSL_Context *context = ACE_SSL_Context::instance();
context->set_mode(ACE_SSL_Context::SSLv23_server);
context->certificate("../ACE-server/server_cert.pem", SSL_FILETYPE_PEM);
context->private_key("../ACE-server/server_key.pem", SSL_FILETYPE_PEM);
if (context->load_trusted_ca("../ACE-server/trusted.pem", 0, false) == -1) {
ACE_ERROR_RETURN((LM_ERROR, "%p\n", "load_trusted_ca"), -1);
}
if (context->have_trusted_ca() <= 0) {
ACE_ERROR_RETURN((LM_ERROR, "%p\n", "have_trusted_ca"), -1);
}
Client side code:
ACE_SSL_Context *context = ACE_SSL_Context::instance();
context->set_mode(ACE_SSL_Context::SSLv23_client);
context->certificate("../ACE-client/client_cert.pem", SSL_FILETYPE_PEM);
context->private_key("../ACE-client/client_key.pem", SSL_FILETYPE_PEM);
I generated the certificates following these instructions: https://blog.codeship.com/how-to-set-up-mutual-tls-authentication/
And checking online, I found that if the .crt and .key files are readable, they should already be in .pem format and there is no need to convert them. So I just changed the extension and used them here.
Any help is appreciated!
My problem apparently was the same as seen here: OpenSSL client not sending client certificate
I was changing the SSL context after creating the SSL Socket. Now the mutual authentication works, but my client crashes when closing the connection. Though I don't know why that is yet.