I created a keystore for Artifactory as follows:
openssl genrsa -des3 -out jetty.key
openssl req -new -x509 -key jetty.key -out jetty.crt
keytool -keystore keystore -import -alias jetty -file jetty.crt -trustcacerts
openssl req -new -key jetty.key -out jetty.csr
openssl pkcs12 -inkey jetty.key -in jetty.crt -export -out jetty.pkcs12
keytool -importkeystore -srckeystore jetty.pkcs12 -srcstoretype PKCS12 -destkeystore keystore
I just created it this week but am already getting a warning that the certificate is expiring soon.
"WARNING - Certificate expires in 26 day(s) ".
why is it expiring so soon and how can I extend the expiry date?
Any help is appreciated.
Thanks
Try adding -days 360 to the openssl req command. From the manual:
-days n
when the -x509 option is being used this specifies the number of
days to certify the certificate for. The default is 30 days.
You can also use keytool directly without openssl. The according parameter is named -validity there.
Related
I have a project based on Google Cloud Platform which involves adding Raspberry Pi devices to Google IoT registry. What I need to do is to generate signed certificates both for registry and for devices in order to ensure that fraudulent devices are not registered.
I already tried generating signed X.509 certificates like this:
openssl req -new -x509 -nodes -days 365 -newkey rsa:2048 -keyout ca.key -out ca.crt
openssl genrsa -out device.key 2048
openssl req -new -days 365 -key device.key -out device.csr
openssl x509 -req -days 365 -in device.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out device.crt
Notice that when promtped I put additional subj information like name, country, email, organisation which according to other SO question should make it work.
After invoking those commands I end up with following files:
ca.crt ca.key ca.srl device.crt device.csr device.key
So what I would do is to add ca.crt as registry certificate and then when I try to upload device.crt as device certificate (type RS256_X509) I get an error Certificate is not supported by Cloud IoT
What could I be doing wrong? I want to make sure that I create correct certificates and link them to registry and device.
I'm writing a custom client & server that I want to communicate securely over the public Internet, therefore I want to use OpenSSL and have both ends do peer verification to ensure that my client isn't mis-directed by a MITM, and likewise that an unauthorized client isn't able to connect to the server.
This is the error received from the server during the SSL_connect / SSL_accept phase:
15620:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:ssl\record\rec_layer_s3.c:1528:SSL alert number 48
I'm running under Windows 10, using OpenSSL 1.1.1. I'm using the following batch file to create them. I enter the ca private key passphrase by hand for obvious reasons.
openssl genrsa -out -des3 ca.key.pem 2048
openssl genrsa -out server.key.pem 2048
openssl genrsa -out client.key.pem 2048
openssl req -x509 -new -nodes -key ca.key.pem -sha256 -days 365 -out ca.cert.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar
openssl req -new -sha256 -key server.key.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out server.csr
openssl x509 -req -in server.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out server.cert.pem -days 365 -sha256
openssl req -new -sha256 -key client.key.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out client.csr
openssl x509 -req -in client.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out client.cert.pem -days 365 -sha256
The intent here is to create a self-signed CA, and then have that directly sign both the client and server keys.
ca.key.pem will be stored in a secure place: on an encrypted veracrypt volume.
Both client and server use the following call to enable peer verification:
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, nullptr);
I'm fairly certain this is a certificate issue because the errors go away if I remove that line.
Answering this myself so that it can help anyone else that might arrive here looking for solutions to this problem. The answer was found in another SO question, but is worth repeating here: The Common Name for the CA cannot be the same as the Common Name for the client and server certificates.
So changing the fourth line of the batch file to this:
openssl req -x509 -new -nodes -key ca.key.pem -sha256 -days 365 -out ca.cert.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=FoobarCA
fixed the problem.
$ openssl req -x509 -new ... -addext basicConstraints=critical,CA:TRUE
This essentially creates a certificate which has 2 basic contrains CA:TRUE extensions:
$ openssl x509 -in ca.cert.pem -text
X509v3 extensions:
...
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Basic Constraints: critical
CA:TRUE
Trying to use the CA to verify the server certificate will not work:
$ openssl verify -CAfile ca.cert.pem server.cert.pem
C = XX, ST = XX, L = XX, O = XX, CN = CA
error 24 at 1 depth lookup: invalid CA certificate
error server.cert.pem: verification failed
Given that this simple check does not work, the client will also not be able to validate the server certificate, resulting in an unknown ca alert:
...:tlsv1 alert unknown ca:...
When skipping the -addext it will create a self-signed certificate as documented, which already has CA:TRUE
$ openssl req -x509 -new ...
...
$ openssl x509 -in ca.cert.pem -text
X509v3 extensions:
...
X509v3 Basic Constraints: critical
CA:TRUE
And using this to verify the server certificate works:
$ openssl verify -CAfile ca.cert.pem server.cert.pem
server.cert.pem: OK
This certificate should also be successfully validated by your client, thus no longer resulting in unknown ca.
I am following this AWS GUIDE on creating self-signed certificates.
But after creating my CA, I try to upload it to AWS IOT I get this error:
Command:
aws iot register-ca-certificate --ca-certificate file://CA_cert.pem --verification-cert file://verificationCert.crt
Error:
An error occurred (CertificateValidationException) when calling the RegisterCACertificate operation: CA certificate is not valid. The CA certificate does not have the basicConstraints extension as true
Any help appreciated!
I have also used AWS IoT and suffered same error, and I found the solution.
Reason of the error
The error occurs because basicConstraints extension in the CA certificate, which means that the certificate is CA so this certificate is able to sign other public keys to generate client certificates, is not set to TRUE.
Note that a client X's certificate contains X's public key signed by CA's private key. Other clients, for example Y, can verify the X's public key using CA's public key.
I think you had the error when you tried to generate CA certificate. The error message indicates that the CA's certificate is not allowed to sign other client public keys.
Below are how I did.
Solution
I assume that you already generate CA's key, rootCA.key.
We need a openssl config file, say rootCA_openssl.conf. Note that you can modify the values.
[ req ]
distinguished_name = req_distinguished_name
extensions = v3_ca
req_extensions = v3_ca
[ v3_ca ]
basicConstraints = CA:TRUE
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = KR
countryName_min = 2
countryName_max = 2
organizationName = Organization Name (eg, company)
organizationName_default = Deeply Inc.
Then generate CA's certificate using the config file, rootCA_openssl.conf.
openssl req -new -sha256 -key rootCA.key -nodes -out rootCA.csr -config rootCA_openssl.conf
openssl x509 -req -days 3650 -extfile rootCA_openssl.conf -extensions v3_ca -in rootCA.csr -signkey rootCA.key -out rootCA.pem
Now we have CA's certificate, rootCA.pem.
Then you can follow the instructions in the AWS IoT documentation.
For example:
# Get the registration code for the use below:
# $ aws iot get-registration-code
openssl genrsa -out verificationCert.key 2048
openssl req -new -key verificationCert.key -out verificationCert.csr
# Put the registration code in Common Name field
openssl x509 -req -in verificationCert.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out verificationCert.crt -days 500 -sha256
#mctuna with this (from AWS):
Generate a key pair.
openssl genrsa -out rootCA.key 2048
Use the private key from the key pair to generate a CA certificate.
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem
I have cert.pfx file, I need to install to be used in Amazon Elastic Load Balancer.
How can I do it?
Extract private key without password. First command will request pfx password and prompt for a password for key.pem; a password for key.pem must be provided. Second command asks for key.pem password provided for 1st command.
openssl pkcs12 -in cert.pfx -nocerts -out key.pem
openssl rsa -in key.pem -out server.key
Extract certificate:
openssl pkcs12 -in cert.pfx -clcerts -nokeys -out cert.pem
Extract certificate chain:
openssl pkcs12 -in cert.pfx -nodes -nokeys -out chain.pem
Certificate chain contains several items. You may need to remove item that refers to your certificate, it's on top and it's not needed. Give a try with/without removing top item.
After that the other items should be placed in reverse order.
server.key is private key in ELB, cert.pem is certificate in ELB, output #4 is certificate chain.
Good luck!
you can easily convert the format of the certificate using the OpenSSL suite.
The process is very easy and a good guide is here: http://www.petefreitag.com/item/16.cfm.
About the different steps (taken from the link I reported above):
# Export the private key file from the pfx file
openssl pkcs12 -in filename.pfx -nocerts -out key.pem
# Export the certificate file from the pfx file
openssl pkcs12 -in filename.pfx -clcerts -nokeys -out cert.pem
# This removes the passphrase from the private key so Apache won't
# prompt you for your passphase when it starts
openssl rsa -in key.pem -out server.key
Now, if you have a linux distro, it is straight forward to install openSSL (yum install openssl on an rpm based distro).
If you don't have a linux distro installed, then the quickest would be to go for a live distribution (I personally love fedora https://getfedora.org/)
I hope this helps
First go to Certificate Manager and import your certificate [cert, key, chain], then create AWS LB with existing certificate.
I'm using boost ssl for server and client, and I have a model for server/client program in my mind, and I'm not sure it's gonna work.
The model I have in my mind is to be the only authority for certificates of my program. My main question is: How can I do that?
In my server program, I define keys as follows:
context_.use_certificate_chain_file("../sslkeys/server.crt");
context_.use_private_key_file("../sslkeys/server.key", boost::asio::ssl::context::pem);
context_.use_tmp_dh_file("../sslkeys/dh512.pem");
I create/sign those keys/certificates using:
$ openssl genrsa -des3 -out server.key 2048
$ openssl req -new -key server.key -out server.csr
$ openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt
$ cp server.key server.key.secure
$ openssl rsa -in server.key.secure -out server.key
$ openssl dhparam -out dh512.pem 512
For my client program, I would like to create a certificate and sign it by my "server.key", because I think (and I could be wrong, please correct me if I'm) that's the way to do it. The client program requires a key using the command:
ctx.load_verify_file("../sslkeys/client.csr");
So I created a key, which I signed using the server key, with the following commands:
$ openssl genrsa -des3 -out client.key 2048
$ openssl req -new -key client.key -out client.csr
$ openssl x509 -req -days 3650 -in client.csr -signkey ../sslkeys/server.key -out client.crt
Now when I run my client and try to connect the server, I get the error: Handshake failed: certificate verify failed
What is wrong in what I'm doing? And how can I achieve the model I mentioned?
If you require any additional information, please ask.
Thanks for any efforts.
Your signing certificate has no rights to sign, because it has not the CA flag set. Signing will still work, but verification will fail. Since there are already lots of guides on the internet which will show in detail how to do it right so you might just look here or here for more details.
Also, using only a 512 bit Diffie-Hellman reduces the security of the key exchange to 512 bit, which is exploitable today (see also Logjam attack). The 2048 RSA key does not help here. And using 512 bit might not even work if you use the latest version of OpenSSL which just increased the minimal size to 768 bits for security reasons.