my website https is failing a PCI scan because of weak SHA-1 certificate Fingerprint. Please see the attached image depicting the SHA-1 fingerprint directly on the certificate....
The certificate is purchased through GoDaddy... I have tried to re-generate new private key and CSR with SHA-256 as below:
openssl req -newkey rsa:2048 -fingerprint -sha256 -nodes -key mydomain.com.key -out mydomain.com.new.csr
But same result. Does anyone know how I can fore Fingerprint to be SHA-2 during the creation of the CSR?
The fingerprint is not an attribute in the certificate, it's a SHA-1 calculation on the certificate content. You can't fail PCI because of a SHA-1 thumbprint. All certs have them... and MD5 thumbprints, etc, because it's just a calculation after the fact.
What's more likely is your certificate is signed with RSA-SHA-1. Any new certificates from public CAs should use stronger signature algorithms, so it should just be "get a new certificate".
Related
i am trying to create a self signed certificate using openssl following the docs https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/configuring-https-ssl.html
i tried to add the generated private and public pem files to my NLB TCP listener as a self signed certificate and it is failing with the below exception.
Error creating listener The imported certificate's configuration is not compatible and will not appear in the list of available certificates for your listeners. Select or upload a different certificate and try again.
I saw that NLB allows RSA 2048 certs. Not sure why the console is showing the error display.
You need to generate a RSA 1024 or 2028 certificate. check the valid certificates that ACM supports. i used the below commands to generate the self signed certificate
openssl genrsa -out private-key.pem 1024
openssl rsa -in private-key.pem -pubout -out public-key.pem
openssl req -new -x509 -key private-key.pem -out cert.pem -days 3600
mention the country, state and domain name. I initially missed the domain name because of which NLB listener wasn't accepting the certificate.
I have a question about TLS/SSL (self-signed certificates)
I am trying to open a connection using several tools (ncat, socat) by using TLS/SSL.
Of course first i need to generate certificate. (Key is a KEY, and Cert is a CERT, PEM is an encoded format). I have found 2 different ways.
1) openssl req -new -x509 -keyout test-key.pem -out test-cert.pem.
2) openssl req -newkey rsa:2848 -nodes -keyout test.key -x589 -out test-cert.crt
cat test-key.key test-cert.crt > test-pem.pem
My questions:
Why at the end of the day we combine CERT with KEY? Should not CERT already have KEY inside?
Why on most tutorials, we send(by listener on socat/ncat) key with cert, if cert already have a key?
(Assume we do not verify cert)
Thanks for support.
SOLVED.
Should not CERT already have KEY inside?
The certificate has the public key inside. The key file is the private key. The public key can be visible to others (as does the rest of the certificate), the private key should be kept secret.
I have read an article on how to create a local SSL certificate. The steps are basically as below:
1. create a key pair
openssl genrsa -des3 -out applicant.key 2048
2. create a certificate signing request
openssl req -new -sha256 -nodes -out applicant.csr -key applicant.key -config someCert.csr.cnf
3. create a cert for the applicant using the ca.key(private key) and cacert.pem (CA certificate)
openssl x509 -req -in applicant.csr -CA cacert.pem -CAkey ca.key -CAcreateserial -out applicant.crt -days 500 -sha256 -extfile localdomain.v3.ext
I got a few question regarding the steps.
a) When we create the key in step 1, is it a key pair or just private key?
b) When creating a certificate signing request in step 2, do we need a public key or private key?
c) When create a cert from CA, why do we need both ca private key and ca certificate? I believe the ca private key is used for digital signature, but what's the purpose of CA certificate?
When we create the key in step 1, is it a key pair or just private key?
applicant.key contains both the public and private elements. You can see them with openssl rsa -text -nout -in applicant.key, or in a more basic form with dumpasn1 or similar.
When creating a certificate signing request in step 2, do we need a public key or private key?
Both. You need the public key as that is going to be certified by the CA. You need the private key as you sign the CSR with this to provide Proof of Possession of the public key.
When create a cert from CA, why do we need both its private key and ca certificate?
Again, both. You need the private key in order to sign the certificate. You also need the CA certificate so that the CA can extract information used during the signing process from it.
As a minimum, this is the Subject field of the CA certificate which is used as the Issuer field of the signed certificate.
Another example is the AuthorityKeyIdentifier extension in the CA certificate, whose value is used as the SubjectKeyIdentfier extension in the applicant's certificate.
However, CAs are at liberty to use whatever they need. For example, Microsoft CAs will check the expiry date on the CA certificate and not issue an applicant a certificate that expires past this date (it truncates the validity of the certificate). In order to do that, it needs access to the CA certificate.
Following the Wakanda SSL Documentation, I've set up a self-signed certificate to test before I engage a certificate authority. However, Firefox lets me know that my webserver is using a SHA-1 certificate (below), which is undesirable- I want at least SHA-256.
Is there a way to control this; do I have any options here?
Wakanda doesn't actually provide a certificate.
Wakanda uses the certificate you provide.
All you need to do is get a new certificate.
You can take your existing CSR to a certificate authority and purchase a signed certificate, and it will be SHA256. You can even use https://www.startssl.com and get a signed SHA256 certificate for free.
If you want to go self signed then just make sure to use the -sha256 parameter like this:
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:1024 -keyout key.pem -out cert.pem
Google is trying to phase out use of SSL certificates using SHA1 hashing algorithm. As result I want to create a SHA2 compliant self signed certificate. I understand the SHA is a hashing algorithm, whilst RSA is an encryption algorithm. I found the following command for producing the key and certificate pair:
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem
Will this produce a certificate using SHA-2 hashing algorithm?
After deploying the certificate, Chrome reports the following:
The hash algorithm used by the certificate issuer to sign a certificate request is unrelated to the certificate request itself. That means the CA might use SHA-2 for the 2048 bit key, but it might also use SHA-1. It might even re-sign the same certificate which was once signed with SHA-1 now with SHA-2.
Currently most (all?) public CA use SHA-2 because SHA-1 is phased out for security reasons.
In your case you use the openssl req command to create not only a certificate request but also sign it, i.e. create a self-signed certificate. Modern versions of openssl will use SHA-2 to sign this new certificate by default, older versions SHA-1. To enforce SHA-2 as the signature algorithm use the -sha256 argument.
I believe I have solved the issue. The command I have been using uses openssl's default hashing algorithm which is SHA-1. To create a SHA-2 hashed certificate one must specify an SHA-2 option. In this case I chose to use SHA-256. Following is the updated command:
openssl req -newkey rsa:2048 -sha256 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem