I have been struggling for the last three hours trying to create an .pfx file using OpenSSL. I have been following this document and have been following the instructions under the Get a certificate using OpenSSL header.
I am at the step here: openssl pkcs12 -export -out myserver.pfx -inkey myserver.key -in myserver.crt and am using the OpenSSL.exe console.
I get the error: unable to load certificates
I have also tried this: x509 -text -in myserver.key and received the error: 0906D06D06C:PEM_read_bio:no start line:.\crypto\pem\pem_lib.b.c:703:Expecting: TRUSTED CERTIFICATE I also get that error if I try myserver.crt.
I seem to get it no matter what I do.
Can someone please help?
I get the error: unable to load certificates
myserver.crt needs to be in PEM format. Does it have ----- BEGIN CERTIFICATE ----- and ----- END CERTIFICATE -----?
myserver.crt should actually be a chain of certificates (and not just the one server certificate). The chain should include all intermediate certificates needed by the client to verify the chain.
You send all the intermediate certificates to solve the "which directory" problem. The "which directory" is a well know problem in PKI. Essentially, the client does not know where to go to fetch the missing intermediate cert. To avoid the problem, you send all intermediates.
I often use Startcom because they offer free Class 1 certificates. When I get the signed server certificate from them (for example, www-example-com.crt), I add their Class 1 Server Intermediate to it. I get their Class 1 Server Intermediate from their website at Startcom CA certs. The one I use is sub.class1.server.ca.pem.
With the www-example-com.crt, my server certificate looks like:
$ cat www-example-com.crt
-----BEGIN CERTIFICATE-----
< My Server Certificate >
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
< Startcom Intermediate >
-----END CERTIFICATE-----
For completeness, the private key (for example, www-example-com.key) is also in PEM format. It uses -----BEGIN RSA PRIVATE KEY----- and -----END RSA PRIVATE KEY-----.
With my server certificate in PEM format (and with the required intermediates) and private key, I then issue the following (which looks like the same command you are using):
openssl pkcs12 -export -in www-example-com.crt -inkey www-example-com.key -out www-example-com.p12
When clients connect, they use the Startcom CA. So, to test the connection (after loading into IIS):
openssl s_client -connect www.example.com:443 -CAfile startcom-ca.pem
The command should complete with "Verify OK":
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 37E5AF0EE1745AB2...
Session-ID-ctx:
Master-Key: 7B9F8A79D3CC3A41...
Key-Arg : None
Start Time: 1243051912
Timeout : 300 (sec)
Verify return code: 0 (ok)
I have also tried this: x509 -text -in myserver.key and received the error...
x509 is for certificates. If you want to dump a key, use OpenSSL's pkey command. See the docs on OpenSSL's pkey(1) command.
keytool -importcert -alias yourdns -keystore /usr/lib/jvm/java-11-openjdk-11.0.15.0.9-2.el7_9.x86_64/lib/security/cacerts -file pathcertificate/.crc
password default = changeit
Related
I recently received a signed certificate to use with haproxy SSL termination. In order for haproxy to use this, I needed to convert the jks file to a pem file. First, I converted the cer files I received into crt, as I had a previous error where haproxy was not able to find the crt files in the pem file. Do this for all certs:
$ openssl x509 -inform PEM -in <CER file here> -out <CRT output file>
I then import the root, intermediate, and service certs to the keystore, which already has the private key:
keytool -importcert -file $CERT -alias $ALIAS -keystore test.jdk
I then convert the jsk file to a p12 file, followed by converting that to a pem file:
$ keytool -importkeystore -srckeystore test.jks -destkeystore test.p12 -srcstoretype jks -deststoretype pkcs12
Enter destination keystore password:
Re-enter new password:
$ openssl pkcs12 -in test.p12 -out test.pem
Enter Import Password:
MAC verified OK
Enter PEM pass phrase:
This generates a pem file with the following format:
Bag Attributes
friendlyName:
localKeyID:
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----
Bag Attributes
friendlyName:
subject=
issuer=
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
Bag Attributes
friendlyName:
subject=
issuer=
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
Bag Attributes
friendlyName:
subject=
issuer=
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
Bag Attributes
friendlyName:
localKeyID:
subject=
issuer=
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
Obviously, there is a lot of information missing from this, as I do not want to share that online; however, the structure is pretty much identical.
When I link this to haproxy:
frontend https
maxconn 2000
bind 0.0.0.0:4000 ssl crt /home/user/config/cert/test.pem
And I run it with haproxy -d -f haproxy.cfg, I'm asked to enter the PEM pass phrase. I need to be able to start haproxy automatically on server start up, so I can't enter this every time I want to run it. Is there any way to remove the pass phrase, or generate a pem file without one? Or can I supply via a script? The script I use to start haproxy on server start up is just the command you see above, with nohup to redirect the output.
Also, when I go to one of the services fronted by haproxy, Chrome still warns me that the CA is not trusted, like when I used a self signed certificate. Is there anything else I need to do beyond what I have above?
You will need to copy the password protected key to a not password protected key.
openssl rsa -in test.pem -out test-password-less.key
To provide the PEM now to HAProxy will you also need the certificate.
cat both Files to one PEM File for haproxy.
cat $CERT test-password-less.key > haproxy-test.pem
or instead remove pem passphrase on e.g an Amazon EC2 Fedora Linux instance:
sudo ssh-keygen -p -f EC2.pem
I'm trying to
kubectl create secret tls foo-secret --key /tls.key --cert /tls.crt
From keys and certs I've used made from LetsEncrypt. This processes makes sense with self-signed certificates, but the files made by LetsEncrypt look like this:
cert.pem
chain.pem
fullchain.pem
privkey.pem
I can convert those pem files, I don't know if --key want's a public key or a private key, and the only option here is privkey.pem. I assume cert is cert.
I can convert private.pem with:
openssl rsa -outform der -in privkey.pem -out private.key
And cert.pem with:
openssl x509 -outform der -in cert.pem -out cert.crt
Is this the right process? Since I'll be using this secret for ingress oauth in place of __INGRESS_SECRET__, is this ingress suppose to have a private key? This ingress is acting as a TLS terminator for other things.
You are correct, you will need to provide your private key for the tls.key portion. However it's a good practice to automate the letsencrypt certificate generate process, using cert-manager. Check out this tutorial. Dong so will automatically create the tls secret resource for you on the cluster.
Your tls.key file is the private key and begins and ends like the following:
-----BEGIN RSA PRIVATE KEY-----
... [your private key]
-----END RSA PRIVATE KEY-----
And your tls.crt is going to be the concatenation of cert.pem and fullchain.pem, and it will look like the following:
-----BEGIN CERTIFICATE-----
...
[your cert content]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
[your fullchain cert content]
-----END CERTIFICATE-----
I have a .pfx file, which can perfectly connect to the remote server when used on a windows client. I want to now connect to server using a linux client.
Problem 1) I used following openssl commands to extract public cert and private key from the pfx file,
openssl pkcs12 -in Name.pfx -nocerts -out priv.pem -nodes
openssl pkcs12 -in Name.pfx -nokeys -out pub.pem
But when I ran following two commands to verify md5 of both files, I found both of them different.
openssl rsa -noout -text -in priv.pem | openssl md5
openssl x509 -noout -text -in pub.pem | openssl md5
Problem 2) I instead used following command to extract single pem file from pfx that has both cert and key.
openssl pkcs12 -in Name.pfx -out bundle.pem
Using this pem file I tried connecting to the remote server, with following command :
openssl s_client -servername 1.2.3.4 -connect 1.2.3.4:1234 -CAfile bundle.pem -state -tls1_2
This gives following output on terminal
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=0 O = "My Name", CN = Name - Local
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server certificate request A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client certificate A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL3 alert read:fatal:handshake failure
SSL_connect:failed in SSLv3 read finished A
140250807310240:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1275:SSL alert number 40
140250807310240:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598:
---
Certificate chain
0 s:/O=My Name /CN=Name - Local
i:/O=My Name /CN=Name - Local
---
Server certificate
-----BEGIN CERTIFICATE-----
<random string of certificate>
-----END CERTIFICATE-----
subject=/O=My Name /CN=Name - Local
issuer=/O=My Name /CN=Name - Local
---
No client certificate CA names sent
Server Temp Key: ECDH, secp521r1, 521 bits
---
SSL handshake has read 1332 bytes and written 206 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: <some string>
Session-ID-ctx:
Master-Key: <some string>
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1495217834
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
I cant figure out why is handshake failing. Stuck for 3 days, where exactly does problem lie.
But when I ran following two commands to verify md5 of both files, I found both of them different.
openssl rsa -noout -text -in priv.pem | openssl md5
openssl x509 -noout -text -in pub.pem | openssl md5
The first command shows textual information about the private key. The second textual information about the certificate which contains the public key. Of course these information are different.
Using this pem file I tried connecting to the remote server, with following command :
openssl s_client -servername 1.2.3.4 -connect 1.2.3.4:1234 -CAfile bundle.pem -state -tls1_2
This uses the certificate as a trusted CA (-CAfile). This is probably not what you want. Instead you want to use the certificate as a client certificate. This should be done as documented by using the options -cert and -key, i.e. -cert bundle.pem -key bundle.pem in your case.
Apart from that -servername should be a hostname and not an IP address. If you don't have a hostname skip this option.
SSL_connect:SSLv3 read server certificate request A
...
SSL_connect:SSLv3 write client certificate A
...
SSL3 alert read:fatal:handshake failure
Since you don't specify the client certificate properly an empty client certificate will be send. But the server expects a valid client certificate and thus report a failed handshake within an SSL alert back to the client.
I'm using boost::asio to establish encrypted connection between client and server applications. I generated a private key file and self signed certificate in the following way:
openssl genrsa -out private_key.pem 2048
openssl req -new -key private_key.pem -out public_key.pem
The generated certificate is:
-----BEGIN CERTIFICATE REQUEST-----
MIICxjCCAa4CAQAwgYAxCzAJBgNVBAYTAkJHMQ4wDAYDVQQIDAVTb2ZpYTEOMAwG
A1UEBwwFU29maWExDDAKBgNVBAoMA0VHVDEMMAoGA1UECwwDU0JTMRMwEQYDVQQD
DApJdmFuIEJvYmV2MSAwHgYJKoZIhvcNAQkBFhFib2JlZmZAZWd0LWJnLmNvbTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM2OyY0BvtnmtxbPw7tblSc+
2TOopefy1/voELFT+6SCfmmXhIkL7HXcbFekc0z3VtCaSpq64Tk7NMGPtm2XiVt7
Yzftw5pItsgyVwGuCk5sAMZ5qtDVjwTJv6m9TEV4hBA91ypYsXgcYBz4CIIw9Zm9
uSJVznEsnraQE8xFE87D6Z78BLSFej83A7YsGqxPRIbNCtismtj1GeLFegnX/u5l
PeyPa6A4bgXKgtWFoOEfdCQhWxZwxER0la16JAbMPuKmM+ZM0JJOPBhwdDmXEpv4
tvZ+LXgVo8v71jKK1eMTjvQA2e3bBqZFtpPi0gvYTENQE1yXoRE479wPDHqrum8C
AwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQAypIZnsX/C63kdeRoQeMOVJa5CObWr
ALxtQIHdaR83SzY6K1Gg3SybHMnQ3wVUr71/tcuCYri6hJAzFKNYo676EdOxH8X4
IJSNQIHUPBRRvcaB2us+wmAEsHhFytzlBdsYNo1UM+QXgDArV/BeHt9R1GYaN9kz
C8ZSf5IYd/8vjDHRzpoeJ5+n4zMONOtCgXZU2WMEa7n9xbumfTnnZmaYGb3y3VVg
FHtEAFsM1K80zKDW7Nech1vLXnJVi/SS5ABl+jqLOdVVqM+WKaowJY6y+U786by4
q55Eoas7JZQIN+g6LeKywWj59CpYpeMczsp/WygKey6JkQ3qi1FiLaUB
-----END CERTIFICATE REQUEST-----
In my program code, I have the following initialization of SSL context structure:
...
, m_sslContext(ssl::context::sslv23)
...
m_sslContext.set_verify_mode(ssl::verify_peer | ssl::verify_fail_if_no_peer_cert);
m_sslContext.use_rsa_private_key_file("private_key.pem", ssl::context::pem);
m_sslContext.use_certificate_file("public_key.pem", ssl::context::pem);
...
But use_ceritificate_file method throws exception with message:
use_certificate_file: no start line
Why does the function fail and what is the correct way to establish a secure connection with boost::asio wrapper around OpenSSL?
As discussed in the comments, a public-key isn't a certificate. Your public_key.pem however isn't a public-key either. It's a certificate-request which you'd normally send to a certificate-authority to sign it for you. Since you want to sign it yourself, you can check out How to create a self-signed certificate with openssl? to see how to sign your request.
I just got an Thawte 123 SSL Certificate and have problems uploading it to AWS to use it with CloudFront as Custom SNI SSL Certificate. AWS refuses the CA Chain. I'm using the Thawte Intermediate CA bundle for SSL Web Server and Thawte Wildcard certificates.
To be able to use my private key I converted it to an RSA key with:
openssl rsa -in private.key -out private-rsa-key.pem`
And tried to upload it with:
aws iam upload-server-certificate --server-certificate-name example.com-certificate --certificate-body file://certificate.pem --private-key file://private.pem --certificate-chain https://search.thawte.com/library/VERISIGN/ALL_OTHER/thawte%20ca/SSL_CA_Bundle.pem --path /cloudfront/example.com/
Resulting in the following error:
A client error (MalformedCertificate) occurred when calling the UploadServerCertificate operation: Unable to validate certificate chain. The certificate chain must start with the immediate signing certificate, followed by any intermediaries in order. The index within the chain of the invalid certificate is: 0
Even Inserting the thawte_Primary_Root_CA.pem into the certificate chain as first immediate signing certificate, doesn't resolve the problem.
A client error (MalformedCertificate) occurred when calling the UploadServerCertificate operation: Unable to validate certificate chain. The certificate chain must start with the immediate signing certificate, followed by any intermediaries in order. The index within the chain of the invalid certificate is: 1
Is the Thawte CA Chain not compatible to AWS?
I am having the same issue right now, and tried everything.
Using SSL123 certificate (My rsa key and pem are ok)
I can't get to work the primary and secondary certs provided by Thawte, in any order.
I tried primary alone, secondary alone, primary+secondary, secondary+primary, also tried with the root cert and also tried with the primary&secondary from:
https://search.thawte.com/library/VERISIGN/ALL_OTHER/thawte%20ca/SSL123_SecondaryCA.pem
https://search.thawte.com/library/VERISIGN/ALL_OTHER/thawte%20ca/SSL123_PrimaryCA.pem
The only thing I can get from ELB is:
Unable to validate certificate chain. The certificate chain must start with the immediate signing certificate, followed by any intermediaries in order. The index within the chain of the invalid certificate is: 0
Where the index is not always -1, but also 0,1 and 2 depending on the order and the number of certs included.
[SOLVED FOR ME]
Apparently, the EC2 instance from which you create the certificate affects. I used a standard EBS instance with default AMI, and transformed the certificate provided by Thwate again, and it did work.
Here the steps:
CSR:
keytool -genkey -keysize 2048 -keyalg RSA -alias mycertificate -keystore keystore.jks
Once Thatwe responds: (Primary is the second certificate in the chain of the email).
Import the three certificates in the keystore.jks
keytool -import -alias Primary -trustcacerts -file Primary.crt -keystore keystore.jks
keytool -import -alias Secondary -trustcacerts -file Secondary.crt -keystore keystore.jks
keytool -import -alias mycertificate -trustcacerts -file mycertificate.cer -keystore keystore.jks
JSK > P12 - Transform keystore.jks into p12 format
keytool -importkeystore -srckeystore keystore.jsk -destkeystore keystore.p12 -srcstoretype jks -deststoretype pkcs12
P12 > PEM - Transform p12 format into pem format
openssl pkcs12 -in keystore.p12 -out keystore.pem -nodes
PEM > RSA PRIVATE KEY - Export the private key in RSA format
openssl rsa -in keystore.pem -text > keystore_rsa.pem
And it did work this time.
you must make sure that the certificate, private key, and certificate chain are all PEM-encoded as following:
-----BEGIN CERTIFICATE----- << -This is my Intermediate CA which signed my CSR
Base64-encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE----- << -This is my Root CA which signed my Intermediate CA
Base64-encoded certificate
-----END CERTIFICATE-----
You don't need to put your signed certificate in the chain.
Just add the intermediate and root ca in the Chain files should be enough.
Using the folliowing as ca chain certificate solves the problem:
https://ssltools.thawte.com/chainTester/webservice/validatecerts/certificate?certKey=issuer.intermediate.cert.57&fileName=thawte%20DV%20SSL%20CA%20-%20G2&fileExtension=txt
It is important to note that the intermediate certificates are not specific to your domain or certificate. So, every certificate issued that is like yours, has the exact same intermediate certificates.
You can think of them a bit like the routing number on your checks. The routing number is needed, but really says more about your bank than it does about you. Your account number, or your certificate in this case, is what is unique to you.
Because of the generic nature of the intermediate certificates there are websites like this one:
https://www.ssl2buy.com/wiki/ssl-intermediate-and-root-ca-bundle
That have all of the intermediate certificates pre-bundled (and in the correct order) for different certificate issuers.