I used the openssl to generate a self-signed certificate using following command
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365ls
I am sending this cert.pem with the curl command
curl --header 'Accept: application/json' --header 'Authorization: Bearer 043473b9-5cf4-3dcc-b7a6-32813f6e4df2' 'https://localhost:8243/pizzashack/1.0.0/menu' --cert cert.pem --key key.pem -k -v
But this fails with the error: error reading X.509 key or certificate file: Error in parsing when sending certificate in Curl Request
How can i overcome this issue?
Here's a solution to this. This occurs when curl is unable to decrypt my key.pem file which is encrypted by default. We can use the -nodes directive when generating the certificate to avoid encrypting the keys.
certificate generated from following request worked correctly.
openssl req -newkey rsa:2048 -x509 -keyout pii_key.pem -out piisp.pem -days 3650 -nodes
Related
I made a tls server by below commands, which will request the client who is connecting to provide a client certificate. And I also simulated a client with the openssl commandline which will provide a client certificate. But it seems that the server didn't check if the client certificate is what exactly we want or not. Do you know how to make the server to do the check?
For the server:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes
openssl s_server -key key.pem -cert cert.pem -accept 44330 -Verify 0
For the client:
openssl req -x509 -newkey rsa:2048 -keyout clientkey.pem -out clientcert.pem -days 365 -nodes
openssl s_client -connect 127.0.0.1:44330 -cert clientcert.pem -key clientkey.pem
... check if the client certificate is what exactly we want or not
You do not specify what you want from the client certificate, that's why it cannot check it. If you want that the client certificate is signed by a specific CA use the -CAfile option as documented:
-CAfile infile
A file containing trusted certificates to use during client authentication and to use when attempting to build the server certificate chain. The list is also used in the list of acceptable client CAs passed to the client when a certificate is requested.
Thus, if you want to make sure that the client certificate is the self-signed certificate you issued (or some other certificate signed by this), use:
openssl s_server -key key.pem -cert cert.pem -accept 44330 -Verify 0 \
-CAfile clientcert.pem
Sorry, I am pretty noob to Digital Certificates.
Basically there is a website, which every time I reach it as https://ip/, It throws me an error saying: Certificate Error: Sorry but you need to provide a client certificate to continue while I did my research I found this article: https://medium.com/#sevcsik/authentication-using-https-client-certificates-3c9d270e8326
Since I don't have access to website's CA, I assume I have the option of bob only to make the site respond to me as a trusted user.
So I did below:
$ openssl req -newkey rsa:4096 -keyout bob_key.pem -out bob_csr.pem -nodes -days 365 -subj "/CN=Alice"
$ openssl x509 -req -in bob_csr.pem -signkey bob_key.pem -out bob_cert.pem -days 365
Enter Export Password: 1234
$ curl --insecure --cert bob.p12 --cert-type p12 https://IP/
I also tried: curl --insecure --cert bob.p12:1234 --cert-type p12 https://IP/
But I still am getting error from site asking to provide a client certificate to continue
Any help? I am in kali-linux env
I am trying to generate the Self-Signed SSL Certificate on windows local system by following steps: https://devcenter.heroku.com/articles/ssl-certificate-self#generate-ssl-certificate
But after running following command in OpenSSL:
x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt
I am getting error:
8780:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expect ing: CERTIFICATE REQUEST
error in x509
How to solve this issue?
The command you search for is:
openssl req -x509 -newkey -sha256 -keyout key.pem -out cert.pem -days 365
As already mention in comments you need to tell openssl this is new key (-newkey)
How can disable the hostnameverfifier in gRPC to avoid exception below?
java.security.cert.CertificateException: No subject alternative names present
The recommended way to use test certificates where the hostname doesn't match is to call ManagedChannelBuilder.overrideAuthority("test-hostname"). This is functionally similar to adding test-hostname to /etc/hosts. This allows you to choose different IPs/DNS names with forAddress()/forTarget() without disabling security.
But it still seems like your certificate is a bit broken. Subject Alternative Name is required; using the certificate's Subject had been deprecated for a decades.
You may also be interested in using gRPC's test certificates. We provide TlsTesting to load them.
server = ServerBuilder.forPort(0)
// Use test cert on server-side
.useTransportSecurity(
TlsTesting.loadCert("server1.pem"),
TlsTesting.loadCert("server1.key"))
// ...
.build().start();
channel = NettyChannelBuilder
.forAddress("localhost", server.getPort())
// Trust test CA on client-side
.sslContext(
GrpcSslContexts.forClient()
.trustManager(TlsTesting.loadCert("ca.pem"))
.build())
// Change hostname to match certificate
.overrideAuthority("foo.test.google.fr")
.build();
Just to elaborate on #Eric Anderson answer. In the gRPC's test certificates he points to there are 2 types *.cnf files used to generate the client and server certs
1.Generate client cert: openssl.cnf
2.Generate server cert: server1-openssl.cnf
at the very bottom of both files you will find the hostnames where you need to add the matching entries for the client and server
for example if you are local testing for client and server resolving on "localhost" then you would need for both openssl.cnf and server1-openssl.cnf to have
[alt_names]
DNS.1 = localhost
after this you would need to regenerate the certificates
here is a simple script based on the grpc-java info here
#!/bin/bash
SERVER_CN=localhost
CLIENT_CN=localhost # Used when doing mutual TLS
TLS_KEY_PSSWD=somepsswd
echo "When prompted for cert information, everything is default except the common name which is set to localhost"
echo Generate CA key:
openssl genrsa -passout pass:TLS_KEY_PSSWD -des3 -out ca.key 4096
echo Generate CA:
openssl req -passin pass:TLS_KEY_PSSWD -x509 -new -nodes -key ca.key -out ca.pem -config conf/ca-openssl.cnf -days 3650 -extensions v3_req -subj "/CN=${SERVER_CN}"
echo "Now that we’re a CA on all our devices, we can sign certificates for any new dev sites that need HTTPS"
echo Generate client key:
openssl genrsa -out client.key.rsa 1024
openssl pkcs8 -topk8 -in client.key.rsa -out client.key -nocrypt
rm client.key.rsa
echo Generate client signing request:
openssl req -passin pass:TLS_KEY_PSSWD -new -key client.key -out client.csr -subj "/CN=${CLIENT_CN}"
echo Generate client cert:
openssl ca -passin pass:TLS_KEY_PSSWD -in client.csr -out client.pem -keyfile ca.key -cert ca.pem -verbose -config conf/openssl.cnf -days 3650 -updatedb
openssl x509 -in client.pem -out client.pem -outform PEM
echo Generate server key:
openssl genrsa -passout pass:TLS_KEY_PSSWD -out server1.key.rsa 1024
openssl pkcs8 -topk8 -in server1.key.rsa -out server1.key -nocrypt
rm server1.key.rsa
echo Generate server signing request:
openssl req -passin pass:TLS_KEY_PSSWD -new -key server1.key -out server1.csr -config conf/server1-openssl.cnf -subj "/CN=${CLIENT_CN}"
echo Generate server cert:
openssl ca -passin pass:TLS_KEY_PSSWD -in server1.csr -out server1.pem -keyfile ca.key -cert ca.pem -verbose -config conf/server1-openssl.cnf -days 3650 -extensions v3_req -updatedb
openssl x509 -in server1.pem -out server1.pem -outform PEM
So I was implementing rush in Orion Context Broker Server instance, and whenever I try to start the contextBroker with the following command:
contextBroker -rush localhost:1234 -https -key privkey.pem -cert cert.csr
, I'm getting the following error:
E#18:16:11 loadFile[1101]: error opening 'privkey.pem': No such file or directory
X#18:16:11 main[1258]: Error loading private server key from 'privkey.pem'
I generated my private key with the following command, I don't know if it's correct:
openssl genrsa -des3 -out privkey.pem 2048
And I generated my certificate with the following command:
openssl req -new -key privkey.pem -out cert.csr
Do I'm doing something wrong?
You have to use absolute path names, i.e.:
contextBroker -rush localhost:1234 -https -key /path/to/privkey.pem -cert /path/to/cert.csr
A note has been added to CLI commands documenation to make this clearer.
In addition, you may find useful the following script on how to generate the needed files:
...
openssl genrsa -out "$keyFileName" 1024 > /dev/null 2>&1
openssl req -days 365 -out "$certFileName" -new -x509 -key "$keyFileName" -subj "$OPTIONS" > /dev/null 2>&1