Trying to achieve a sort of self-signed PKI setup utilizing openssl on RHEL, with a few caveats. I will attempt to provide as much information as possible here.
Versions: RHEL 6.7 | OpenSSL 1.0.1e-fips 11 Feb 2013
Caveats/constraints on the script: this script will be utilized to create multiple key sets - by default, one root keypair and cert and two client keypairs and certs per run. User input is asked for for file location, filename and passphrase on the client keys. All this was fairly straightforward, and I had a script that would run these commands on user request, and utilized the openssl.cnf file to point back to the root key to sign. I had used sed to change the location pointers in openssl.cnf based on filename originally, and was successfully able to sign the client cert.
However, there are two major caveats to this:
I was asked to change the script so that it is not dynamically the script or other files per each run, meaning openssl.cnf should not be edited on the fly if possinble. If this is needed to function however, then it should be fine.
The user needs to be able to run multiple sets of this script ad hoc, especially with regards to the client keypairs (I have the root script and the client generation script separate in a user selectable menu). That is to say, generating the client keypair is requisite on having a root key to associate with, but can be done multiple times, and the client key script should ask the user with which root key to associate and sign from?
Because of these constraints, it didn't seem that editing openssl.cnf was a prudent option, and not very scalable. So, given this info my question which I've been unable to figure out is simply:
Is there a way to point a client key to a variable which would be the root key cert to sign? (Rather than utilizing openssl.cnf for the 'certificate' and 'private_key' entries?)
As of now, I have:
root key & cert:
openssl req -config $dir/openssl.cnf -new -x509 -days 3652 -nodes -sha384 -newkey ec:ec-secp384r1.pem -keyout $userdir/${rootName}_private.key -out $userdir/${rootName}.crt -subj "stuff_here"
...
export rootName
client keys & certs:
read -p "Which root key do you want to associate this client keypair with? Please type absolute filepath and filename (ending in .key); rkAssoc #STILL NEED TO USE THIS VARIABLE
##KEY GENERATION
openssl req -newkey ec:ec-secp384rp1.pem -keyout $userdir/{$clientName}_privat.key -out $userdir/client/${clientName}.csr -subj "Stuff_here"
##SIGN CSR
openssl ca -config $dir/openssl.cnf -policy policy_anything -extensions usr_cert -days 730 -notext -md sha384 -in $userdir/client/${clientName}.csr -out $userdir/client/${clientName}_signedprivatekey.pem && echo "Client key created."
So I guess,
1) Did i do the client signing correctly (something seems off about it but not sure)
2) instead of referencing -req openssl.cnf I presume there is probably some kind of flag where you could do something more like
openssl ca ... -cert ${rkAssoc}
is this remotely correct or am I way off?
Thanks in advance for anyone who lends a hand.
OpenSSL has multiple ways of doing the same thing. You found one way of signing a CSR, with openssl ca. openssl x509 can act as a mini CA, so to eliminate the need for a config file, you could do something like:
openssl x509 -req -in /tmp/mykey.csr.pem -CA /path/to/ca/mycacert.pem -CAkey /path/to/ca/cakey engine -CAserial /path/to/ca/myca.srl -days 3600 -out /tmp/mykeypub.cert.pem
Where -CA points to your root CA cert, and -CAkey to your root CA key.
Related
I have created a socketcluster nodejs app. I followed their official docs to deploy the service to Google K8s Engine. However the ingress service is not running up and complains about :
Error:googleapi: Error 400: The SSL key is too large., sslCertificateKeyTooLarge
I tried following certificates:
4048 Key size certificate from Let'sEncrypt
2048 Key size using cert created using Open SSL.
Both of them result the the same error.
Do any one know how do I resolve this? And where do I get proper certificate for enabling TLS?
IIRC, only RSA-2048 and ECDSA P256 keys are supported:
openssl genrsa -out PRIVATE_KEY_FILE 2048
openssl ecparam -name prime256v1 -genkey -noout -out PRIVATE_KEY_FILE
I also struggled due to this error on using Letsencrypt certs with 4096bit private key to a GKE ingress - even creating the secret worked fine for [1].
Finally overcame with editing "/etc/letsencrypt/cli.ini"
rsa-key-size = 2048
issued new certificate, keyfile and put those into secret.
[1] https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-multi-ssl
On Cloud Shell, GCP with "openssl" and "gcloud", I tried to create a self-managed SSL certificate first running this command below to create "myCert.crt" and "myKey.key":
openssl req -new -newkey rsa:4096 -x509 -days 365 -nodes -out myCert.crt -keyout myKey.key
Then, ran this command below to create the self-managed SSL certificate "mycert" using "myCert.crt" and "myKey.key":
gcloud compute ssl-certificates create mycert --certificate=myCert.crt --private-key=myKey.key
But I got a similar error to yours:
ERROR: (gcloud.compute.ssl-certificates.create) Could not fetch
resource:
The SSL key is too large.
So I changed "rsa:4096" to "rsa:2048" then ran the first command again:
// "4096" is changed to "2048"
openssl req -new -newkey rsa:2048 -x509 -days 365 -nodes -out myCert.crt -keyout myKey.key
Then, ran the second command again:
gcloud compute ssl-certificates create mycert --certificate=myCert.crt --private-key=myKey.key
Finally, I could create the self-managed SSL certificate "mycert":
Created
[https://www.googleapis.com/compute/v1/projects/myproject-923743/global/sslCertificates/mycert].
NAME: mycert TYPE: SELF_MANAGED CREATION_TIMESTAMP:
2022-01-22T07:22:26.058-08:00 EXPIRE_TIME:
2023-01-22T07:22:08.000-08:00 MANAGED_STATUS:
I am trying to integrate with a 3rd party API using two way SSL authentication. The documention provided by them is for JAVA and I am using NodeJS. I am new to this and really grasping at straw here. In document it is mentioned to generate a self signed certificate and use private key of that certificate with the public cetificate from them to create a PKCS 12 file and use it to call the API.
Below is the excerpt from the documentation to
Create a self signed certificate
keytool -genkey -keyalg RSA -alias <aliasName>-keystore selfsigned.jks -validity <days> -keysize 2048
Import JKS to key store
KeyDBs could be any format PFX, JKS or P12. Listing the certificates from > the Keystores, Go to bin directory of Java library, It should have a Private-> Cert entry in the List of the certificates.
Keytool -list -v -keystore <Keystore Name>
If the KeyDB is not present create a Keydb using the Private key and Public Certificate provided through openSSL.
Create P12 from key
openssl pkcs12 -export -in mycert.crt -inkey <mykey.key> -out mycert.p12 -name tomcat -CAfile <myCA.crt> -caname root –chain
Create JKS from P12
keytool -v -importkeystore -srckeystore <key.p12> -srcstoretype PKCS12 -destkeystore <key.jks> -deststoretype JKS
To Verify: KeyDBs could be any format PFX, JKS or P12. Listing the certificates from the Keystores, Go to bin directory of Java library, It should have a Private-Cert entry in the List of the certificates.
Keytool -list -v -keystore <Keystore Name>
I am facing problem in creating the PKCS 12 file. I created self signed certificate using openssl (provided with git) via below mentioned commmands
Creating request and private key
openssl req -new -newkey rsa:2048 -nodes -keyout privatekey.key -out certificatereq.cer
Creating Certificate using the request and key
openssl x509 -req -days 365 -in certificatereq.cer -signkey privatekey.key -out selfsigned.crt
Upon creation of certificate I used it to create PKCS 12 file as mentioned in documentation above via below mentioned command
openssl pkcs12 -export -in selfsigned.crt -inkey privatekey.key -out outpkcs12file.p12 -name myname -CAfile thirdpartypublic.crt -caname mycaname -chain
but getting the error Error self signed certificate getting chain. I tried by installing the self signed certificate in my system also and getting the same error. If I remove the -chain (not sure what it does, but found few commands without -chain) agrument there is no output in terminal. The third party's certificate is CA signed.
I am trying to set up Mosca MQTT broker which is based on node.js
From the documentation below,
https://github.com/mcollina/mosca/wiki/TLS-SSL-Configuration
var mosca = require('mosca')
var SECURE_KEY = __dirname + '/../../test/secure/tls-key.pem';
var SECURE_CERT = __dirname + '/../../test/secure/tls-cert.pem';
Where do I get tls-key.pem and tls-cert.pem?
From the link https://github.com/mcollina/mosca/wiki/TLS-SSL-Configuration in your question, you are directed to another link https://nodejs.org/api/tls.html#tls_tls_ssl
Now, follow the instructions in this link.
$ openssl genrsa -out tls-key.pem 2048
$ openssl req -new -sha256 -key tls-key.pem -out ryans-csr.pem
$ openssl x509 -req -in ryans-csr.pem -signkey tls-key.pem -out tls-cert.pem
There you go. You should have your pem files.
It all depends on what you want to use the broker for.
If it's for simple private playing then you can create your own self signed certificate with openssl (details here)
openssl genrsa -des3 -out tls-key.pem 1024
openssl req -new -key tlk-key.pem -out server.csr
cp tlk-key.pem tls-key.pem.org
openssl rsa -in tls-key.pem.org -out tls-key.pem
openssl x509 -req -days 365 -in server.csr -signkey tls-key.pem -out tls-cert.pem
or if you are planning to do client authentication using certificates as well then can create your own Certificate CA and create a certificate signed by this. This is a longer process, details can be found here
Or finally if you want to make a service available publicly then you probably should really get a certificate signed by a real CA. Normally these would cost money, but the Let's Encrypt group will issue certificates with 90days of life for free and have an API which lets you renew the certificate before it expires. Details here
I am trying to use push notifications through my nodejs server deployed in openshift rehat server. I could not find any documentation/discussion to generate apns certificate in openshift.
I tried generating a certificate, but getting an error while generating CSR using this command
openssl genrsa -out sz.key 2048
Error: unable to write 'random state'
e is 65537 (0x10001)
After some googling, I see one option is to use aerogear. But I want to use my own server to handle the notifications.
Is there any other option to generate a certificate in openshift server?
Thanks developercorey for your help. But i still see the error.
Finally generated certificate for my openshift server using this script
openssl x509 -in aps_production.cer -inform DER -out myProdCert.pem
The private key associated with the SSL certificate can be exported from the Keychain Access application on your Mac computer. - mykey.p12
openssl pkcs12 -in mykey.p12 -out myProdKey.pem -nodes -clcerts
openssl s_client -connect gateway.push.apple.com:2195 -cert myProdCert.pem -key myProdKey.pem
Hopefully this will help somebody.
Try this command:
HOME=~/app-root/data/ openssl genrsa -out sz.key 2048
Basically it is trying to write some temp data into your $HOME, but you can't write to that directory, so it won't work, but it does give somewhat of a cryptic error message.
I'm using OpenSSL to avoid pay for it. In my server is runing IIS 8 and Windows Server 2012.
I created my certificate this way:
Used IIS to create a certificate request
Used the following command to create a RSA private key
openssl genrsa -des3 -out cakey.pem 2048
After that I used this command to generate a certificate
openssl req -new -key cakey.pem -x509 -days 1825 -extensions v3_ca -out ca.crt
Finally I signed the certificate request using this:
openssl x509 -req -days 365 -in certreq.txt -CA ca.crt -CAkey cakey.pem -CAcreateserial -out iis.cer
But when I navigate to the website I get an "error" telling me that this is an "Untrusted certificate": The security certificate presented by this website was not issued by a trusted certificate authority.
What you get from OpenSSL tool is a self signed certificate. Of course it is not trusted by any browser, as who can say you are worth the trust.
Please buy a certificate if you want to set up a public web site. That's something you must pay, just like the public domain name.
Instead, if you are hosting an internal web site for your company, there are ways to set up your own CA, such as using Microsoft Active Directory Certificate Services.
Updated in 2018: Today there are more options to get free certificates, such as Let's Encrypt. Check them out and make good use of them.
Did you install your CA certificate into your browser before trying to visit the IIS server running the certificate you generated under the CA hierarchy? Here's some information about that step.