I'm trying to connect to Apple's push notification server using my key and certificate
openssl s_client -connect gateway.sandbox.push.apple.com:2195 -cert MyApp.pem -key MyApp.pem
I keep getting the following error. Does anyone know what might be wrong?
7495:error:20074002:BIO routines:FILE_CTRL:system lib:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/bio/bss_file.c:358:
unable to load client certificate private key file
You might be entering the wrong pass phrase.
Related
I am working on integrating elasticsearch with gitlab. So, i have created one elasticsearch server and enabled https for it by using self signed certificates. when i tried to integrate with gitlab its giving me 500 error and below is the log i got.
Faraday::SSL::SSLError SSL_connect returned=1 errno=0 state=error: certificate verify failed (self signed certificate in certificate chain)
From this i think gitlab is unable to verify the certificate of elastic search. Is there a way to disable this verification or any other way to make sure that my elasticsearch gets integrated.
Any help would me much appreciated, Thank you.
You need to add into trusted path /etc/gitlab/trusted-certs.
once you will put the crt, der or pem files you can validate with next steps.
Please, validate the symlinks: sudo ls -al /opt/gitlab/embedded/ssl/certs
1.1. Check certs:
echo | /opt/gitlab/embedded/bin/openssl s_client -connect HOSTNAME:port
View a certificate’s details in text form using x509. Be sure to replace /path/to/certificate.crt with the certificate’s path:
/opt/gitlab/embedded/bin/openssl x509 -in /path/to/certificate.crt -text -noout
Fetch a certificate from a server and decode it. This combines both of the above commands to fetch the server’s SSL certificate and decode it to text:
echo | /opt/gitlab/embedded/bin/openssl s_client -connect HOSTNAME:port | /opt/gitlab/embedded/bin/openssl x509 -text -noout
Links:
https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates
https://docs.gitlab.com/omnibus/settings/ssl/ssl_troubleshooting.html
I am trying to login into a private docker registry using docker community edition 18.06 for Mac, but i am getting this error while docker login from cli-
Error response from daemon: Missing client certificate domain.cert for
key domain.key
First, I installed CA certificate in ~/.docker/certs.d/myprivaterepo:port using below commmands:
$ openssl genrsa -out client.key 4096
$ openssl req -new -x509 -text -key client.key -out client.cert
And it gave me error -
Error response from daemon: Get
https://myprivaterepo:port/v2/: Service Unavailable
Then i generated the certificate with '.crt' format using above command and it started giving me this error:
Error response from daemon: Missing client certificate client.cert for
key client.key
I am assuming it requires a key and both .crt and .cert certificates to be present. I infact tried creating another .cert certificate with another key, but it gave me below error:
Error response from daemon: tls: private key does not match public key
I referred to docker documentation- https://docs.docker.com/engine/security/https/, but could not resolve issue.
Can you please let me know how to generate the combination of these 2 certificates.
Thanks in advance!
For me, renaming and putting the crt file in /usr/local/share/ca-certificates/ worked:
# copy and rename the file
cp client.crt /usr/local/share/ca-certificates/<my-private-repo>:<port>.crt
# update certificates
sudo ca-update-certificates
# restart docker daemon
sudo service docker restart
I'm using Jython 2.latest and I cannot for the life of me figure out how to securely (i.e. not turning off verification) to download an HTTPS link.
All I can seem to find are examples where you turn off validation.
I'm using code like
thefile = urllib2.urlopen("https://example.com/index.php")
with open(save_path, 'wb') as output:
output.write(thefile.read())
logging.info("Successfully downloaded %s", save_path)
But I get a handshake error, totally expected.
So I've generated the ssl cert:
openssl s_client -showcerts -connect example.com:443 </dev/null 2>/dev/null|openssl x509 -outform PEM >example.pem
So now I have the PEM file. Now what do I do, does anyone know? Am I stuck installing the PEM file into the keystore?
Link here: Problem with Jython urllib2.urlopen for HTTPS pages says that you can only add it to the java keystore.
Tried to form a secure cluster in nifi 1.0.0 by following the instructions from the below link
http://bryanbende.com/development/2016/08/17/apache-nifi-1-0-0-authorization-and-multi-tenancy
I have generated keystore and truststore file in the target folder, from nifi-cert.pem and nifi-key.key I have generated the p12 file and loaded it in browser
After starting the nif instances, nodes has been connected and exchanging the heartbeat signals between them and the port specified are listening to their numbers but when we launch the UI, It's not viewing in the browser
Update:
Update:
Update:
Update:
due to org.apache.nifi.cluster.protocol.ProtocolException: Failed marshalling protocol message in response to message type: CONNECTION_REQUEST due to java.net.SocketException: Software caused connection abort: socket write error
org.apache.nifi.cluster.protocol.ProtocolException: Failed marshalling protocol message in response to message type: CONNECTION_REQUEST due to java.net.SocketException: Software caused connection abort: socket write error
at org.apache.nifi.cluster.protocol.impl.SocketProtocolListener.dispatchRequest(SocketProtocolListener.java:176) ~[nifi-framework-cluster-protocol-1.0.0.jar:1.0.0]
at org.apache.nifi.io.socket.SocketListener$2$1.run(SocketListener.java:136) [nifi-socket-utils-1.0.0.jar:1.0.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_91]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_91]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
There are a couple steps you can take to continue debugging:
Run NiFi with Java TLS (SSL) debugging enabled. In conf/bootstrap.conf add the line java.arg.15=-Djavax.net.debug=ssl,handshake (ensuring that 15 is a number that does not conflict with your existing list of arguments). This will add a substantial amount of log output, but will explicitly document any TLS handshake negotiation attempts.
Use the OpenSSL s_client tool to debug the connection. Running the command below will attempt a handshake negotiation with additional log output: $ openssl s_client -connect <host:port> -debug -state -cert <path_to_your_cert.pem> -key <path_to_your_key.pem> -CAfile <path_to_your_CA_cert.pem>
Substitute your server for <host:port>
Substitute your public key certificate for <path_to_your_cert.pem>
Substitute your private key for <path_to_your_key.pem>
Substitute your server's public key certificate or the CA public key certificate for <path_to_your_CA_cert.pem>
You can extract the public key certificate and private key from your PKCS12 keystore by using the following commands
Extract the private key: $ openssl pkcs12 -in CN\=Andy_LoPresto_OU\=Apache_NiFi.p12 -nocerts -out client.key
Extract the public key: $ openssl pkcs12 -in CN\=Andy_LoPresto_OU\=Apache_NiFi.p12 -clcerts -nokeys -out client.pem
As #bryan-bende pointed out above, the error message in the browser screenshot you shared does seem to indicate that the TLS cipher suites cannot be negotiated due to a protocol version incompatibility. The commands above will output all available cipher suites for the connection. You can also use a tool like CipherScan to enumerate these explicitly.
One possible issue is that Java 7 defaults to TLS 1.0 and Java 8 to TLS 1.2. What OS and JRE are you using to host NiFi?
In some rare cases, a user deploys NiFi with a keystore that does not actually contain an RSA key, and TLS handshake negotiation fails because "no cipher suites are available", when the issue is really that all of the available cipher suites require an RSA key (if not to encrypt the actual channel data, at least to sign the ephemeral keys). Can you verify that the keystore you provided NiFi has a valid (check dates as well) private key available?
Hopefully these steps help you diagnose the issue. If you can provide more information, we're happy to work with you to investigate further.
For various reasons I have created a simple HTTP server, and added SSL support via OpenSSL. I'm using self-signed certificates. IE, Firefox and Chrome happily load content as long as I add the CA to the trusted root CAs.
However, wget (even when using the --no-check-certificate flag) reports:
OpenSSL: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
If I run the OpenSSL client against my server using:
openssl s_client -connect dnvista:82 -debug
I get back:
verify error:num=19:self signed certificate in certificate chain
verify return:0
and then
5852:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:.\ssl\s3_pkt.c:1060:SSL alert number 40
5852:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:.\ssl\s23_lib.c:188:
Do wget and the OpenSSL client simply not work with self-signed certificates?
UPDATE:
For anyone that comes along later, adding this code helped with the OpenSSL client and Firefox:
EC_KEY *ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
SSL_CTX_set_tmp_ecdh(ctx, ecdh);
EC_KEY_free(ecdh);
I checked the man page of wget, and --no-check-certificate only seems to affect the server certificate. You need to specify your self-signed certificate as a valid CA certificate locally.
To do this, specify the certificate as --ca-certificate=... in wget and -CAfile in the s_client case.
You can also install trusted root CA certificates into OpenSSL in one of a number of ways:
Put your CA certificate in /etc/pki/tls/certs or equivalent directory, then create a link based on the certificate hash. See http://gagravarr.org/writing/openssl-certs/others.shtml#ca-openssl for details.
Append your CA certificate to /etc/pki/tls/certs/ca-bundle.crt, /etc/pki/tls/cert.pem, or equivalent CA bundle.