I'd like to build my own self-signed CA structure to use in my applications. The idea is presented by the following picture:
So, to summarize it, I want a CA that has several levels of intermediate certificates.
For instance I want to create a Root CA that signs all of my apps and then create an intermediate cert for my first app APP_1. This app is used by several companies so I want that every company has it's own intermediate cert just for them which is signed by APP_1 (you can imagine this intermediate cert as a "child" of APP_1 cert). Company intermediate cert then signs end-user's certificate which he uses on his device.
Is it possible to create this cert hierarchy scheme with OpenSSL?
I've tried to create an example of this scheme and it went well until I tried to verify Company_1 intermediate cert. The verification with the chain was successful, but the verification with the intermediate cert that created this one failed. The command that fails is this one:
openssl verify -CAfile /CA/app_1/certs/app_1.cert.pem /CA/app_1/company_1/certs/company_1.cert.pem
The error is as it follows:
error 2 at 1 depth lookup: unable to get issuer certificate
error /CA/app_1/company_1/certs/company_1.cert.pem: verification failed
What am I doing wrong? Should I also verify the Company_1 intermediate with Root CA as I do with APP_1?
openssl verify by default wants to build the full chain. But you only provide the leaf certificate and the chain certificate and not the root certificate (which is signed by itself). To accept a chain certificate as the final trust anchor instead of a root certificate use the -partial_chain option:
$ openssl verify -partial_chain -CAfile app_1.cert.pem company_1.cert.pem
Related
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs. On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
I know the truststore is to verify the 3rd party certificate during handshake
My question is what should my truststore actually store during handshake?
Youtube.pem (the CA signed certificate sent from 3rd part)
Google.crt (the CA certificate)
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs.
Yes, but you only need a keystore if you want to use client side authentication. Note that "keystore" and "truststore" indicate how the store is used, they can be of the same type (e.g. PKCS#12) and even the same file.
On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
No, YouTube is a service, it has a leaf or end-entity certificate. The root certificate is that of a third party CA. The end-entity certificate is usually signed by an intermediate CA certificate, and that is in turn signed by a self signed root certificate.
I know the truststore is to verify the 3rd party certificate during handshake
It is used to validate and verify the trust path from leaf certificate to a trust anchor in your truststore. The trust anchor is usually one of the root certificates stored in your truststore. The leaf certificate is indicated by the end entity / server, the intermediate certificates are usually sent by the server as well, but they could also be retrieved from a cache.
In the case of YouTube, the Google root CA is used, possibly using the GlobalSign root through a linked certificate if the Google root is not present in the trust store.
So your truststore should either contain the Google root certificate or the GlobalSign root for the connection to work in this example.
This question already has answers here:
SSL working in chrome but sometimes in Firefox and not on IOS, Android or Blackberry
(2 answers)
Closed 1 year ago.
I've put together a Linux (Centos 7) server to serve eye-n-sky.net.
Serving content from that site to browsers on Win10 and Linux systems works beautifully. However, when I use openssl to access the site,
openssl s_client -connect eye-n-sky.net:443
the site certificate is rejected,
Verify return code: 21 (unable to verify the first certificate)
I've concluded that the way a browser verifies the certificate is different from what openssl does. Am I on the right track?
I've tested this on three different openssl instances (Debian, Centos, FreeBSD) and have consistent results.
Openssl as a client to other sites, e.g. www.godaddy.com, microsoft.com, work fine, being able to verify the certificate against the installed CA chain.
Believing that I was missing a CA cert, I used the -CAfile option to specify the possibly missing cert, to no effect.
What am I missing? I'm guessing that openssl has a stricter verification discipline, but I don't know where that gets configured.
Thanks,
Andy
Summary: yes, eye-n-sky was providing only it's cert when it needed to include the intermediate and root certs.
However, it took me forever to figure out that my Apache version did not support including the chain in the server cert file. Instead, I had to provide the chain file separately in an SSLCertificateChainFile directive.
OpenSSL's command-line s_client utility has nothing built in to validate the server's certificate. Browsers have a built-in list of trusted certificates to verify the server certificate against.
You have to supply the trusted certificates using options such as -CAfile file or -CApath directory. Per the OpenSSL 1.1.1 s_client man page:
-CApath directory
The directory to use for server certificate verification. This
directory must be in "hash format", see verify(1) for more
information. These are also used when building the client certificate
chain.
-CAfile file
A file containing trusted certificates to use during server
authentication and to use when attempting to build the client
certificate chain.
Note the use of words such as "certificate chain". If you go to godaddy.com you'll see that the server's cert is for *.godaddy.com, but it was signed by Go Daddy Secure Certificate Authority - G2, and that intermediate certificate was signed by Go Daddy Root Certificate Authority - G2 - a different certificate. There's a total of three certificates in that chain.
Verify return code 21 is "no signatures could be verified because the chain contains only one certificate and it is not self signed", so if your CA file only had the certificate from Go Daddy Root Certificate Authority - G2 and not the one from Go Daddy Secure Certificate Authority - G2, OpenSSL would see from the server's cert itself that it was signed by Go Daddy Secure Certificate Authority - G2 and could go no further - it doesn't have that cert to see who signed it.
In accordance with Microsoft a minimum key length for a certificate should be of 1024 bits since August 2012. I have created a self-signed certificate having a key length of 4096 bits. But the certificate information shows the following error:
When I inspected the public key length it shows the following screen:
But instead of having "This certificate is OK." as a status, I am getting the following error:
How can I resolve this issue?
Thanks...
Where do you see a self-signed certificate? Self-signed certificate is the certificate where Subject and Issuer fields are the same. In your case, it is not self-signed.
I can suspect, that the certificate was either, not signed by InfoValley Inc., or signature algorithm is not recognized on your system. Can you tell us the following information:
Authority Key Identifier extension value from leaf certificate
Signature algorithm used to sign leaf certificate (2nd and 3rd fields)
Subject Key Identifier extension value from InfoValley Inc. certificate
I'll explain at least one other way that you can get an invalid digital signature that happened to me. I have a set of scripts that build may certificates and a set of scripts that installs certificates in the windows certificate store. The script that installs the certificates first deletes the certificates that I'm going to install and then installs the new certificates. I thought the script was working just fine, but it turns out I had little bug in the script. I have one Trusted Root CA certificate that is used to sign my Intermediary Trusted Root CA certificates. The problem was that I chose the wrong "certificatestorename" for the trusted root certificate. So, instead actually deleting my trusted root certificate before I installed it, I ended up creating a second trusted root ca certificate in the Trusted Root Certificate Authorities store with the same distinguished name. And that's what cause my 2nd level intermediary CA certificates to report that they had an invalid digital signature.
What made this problem a little difficult to spot was that if I looked at installed 2nd level intermediary CA certificates after being install in the windows certificate store, those 2nd level intermediary CA certificates all showed that the "This certificate is "OK" and no issues with the certificate chain. The problem caused by the two trusted root certificates with the same distinguished name didn't exhibit any problems until I tried to validate a certificate that was signed by one of my 2nd level intermediary CA certificates. It's when I look at those certificates that I saw my 2nd level intermediary CA certificates all had an invalid digital signature.
So, this is at least one way that I observed that you can get this error message. Technically speaking, the error means that the issuer of the certificate cannot validate the signature of the given certificate, which is not the same thing as not finding the issuer certificate in the trusted store. Others have reported that this problem can occur in windows if you generate a certificate whose key length is 512.
Now i have a X509 leaf certificate. From the certification path to see, there's a intermediate cert and a root cert in it.
I want to generate the intermediate cert(..CA- G3) and the root cert(VerSign). Currently, my way is to double click the intermediate one and then click "Copy to file.." to export it. Do same for the root one too. Is this way to correct to generate intermediate/root certs?
From my test result, it seems the generated root cert with wrong fingerprint. The fingerpring doesn't match the one on server side.
Anyone can help on how to generate intermediate/root certs correctly?
You have fundamental misunderstanding of certificates and certificate chains.
CA and Root certificates are searched for and found, not generated.
Some certificates include location of their CA certificate in the body of the certificate (in special certificate extension). For others you need to look in your CA certificates storage (this is what Windows does). Sometimes chains are sent together with end-entity certificate (depending on data format). Finally, sometimes CA and Root are just not available.
[supply the answer... , maybe this is an alternative approach to get all certs that the SSL server using]
To retrieve the ntermediate and root certs by OpenSSL command:
openssl s_client -showcerts -connect [host]:[port]
I am trying to verify an SSL connection to Experian in Ubuntu 10.10 with OpenSSL client.
openssl s_client -CApath /etc/ssl/certs/ -connect dm1.experian.com:443
The problem is that the connection closes with a Verify return code: 21 (unable to verify the first certificate).
I've checked the certificate list, and the Certificate used to sign Experian (VeriSign Class 3 Secure Server CA - G3) is included in the list.
/etc/ssl/certs/ca-certificates.crt
Yet I don't know why it is not able to verify the first certificate.
The entire response could be seen here:
https://gist.github.com/1248790
The first error message is telling you more about the problem:
verify error:num=20:unable to get local issuer certificate
The issuing certificate authority of the end entity server certificate is
VeriSign Class 3 Secure Server CA - G3
Look closely in your CA file - you will not find this certificate since it is an intermediary CA - what you found was a similar-named G3 Public Primary CA of VeriSign.
But why does the other connection succeed, but this one doesn't? The problem is a misconfiguration of the servers (see for yourself using the -debug option). The "good" server sends the entire certificate chain during the handshake, therefore providing you with the necessary intermediate certificates.
But the server that is failing sends you only the end entity certificate, and OpenSSL is not capable of downloading the missing intermediate certificate "on the fly" (which would be possible by interpreting the Authority Information Access extension). Therefore your attempt fails using s_client but it would succeed nevertheless if you browse to the same URL using e.g. FireFox (which does support the "certificate discovery" feature).
Your options to solve the problem are either fixing this on the server side by making the server send the entire chain, too, or by passing the missing intermediate certificate to OpenSSL as a client-side parameter.
Adding additional information to emboss's answer.
To put it simply, there is an incorrect cert in your certificate chain.
For example, your certificate authority will have most likely given you 3 files.
your_domain_name.crt
DigiCertCA.crt # (Or whatever the name of your certificate authority is)
TrustedRoot.crt
You most likely combined all of these files into one bundle.
-----BEGIN CERTIFICATE-----
(Your Primary SSL certificate: your_domain_name.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Intermediate certificate: DigiCertCA.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Root certificate: TrustedRoot.crt)
-----END CERTIFICATE-----
If you create the bundle, but use an old, or an incorrect version of your Intermediate Cert (DigiCertCA.crt in my example), you will get the exact symptoms you are describing.
SSL connections appear to work from browser
SSL connections fail from other clients
Curl fails with error: "curl: (60) SSL certificate : unable to get local issuer certificate"
openssl s_client -connect gives error "verify error:num=20:unable to get local issuer certificate"
Redownload all certs from your certificate authority and make a fresh bundle.
I came across the same issue installing my signed certificate on an Amazon Elastic Load Balancer instance.
All seemed find via a browser (Chrome) but accessing the site via my java client produced the exception javax.net.ssl.SSLPeerUnverifiedException
What I had not done was provide a "certificate chain" file when installing my certificate on my ELB instance (see https://serverfault.com/questions/419432/install-ssl-on-amazon-elastic-load-balancer-with-godaddy-wildcard-certificate)
We were only sent our signed public key from the signing authority so I had to create my own certificate chain file. Using my browser's certificate viewer panel I exported each certificate in the signing chain. (The order of the certificate chain in important, see https://forums.aws.amazon.com/message.jspa?messageID=222086)
Here is what you can do:-
Exim SSL certificates
By default, the /etc/exim.conf will use the cert/key files:
/etc/exim.cert
/etc/exim.key
so if you're wondering where to set your files, that's where.
They're controlled by the exim.conf's options:
tls_certificate = /etc/exim.cert
tls_privatekey = /etc/exim.key
Intermediate Certificates
If you have a CA Root certificate (ca bundle, chain, etc.) you'll add the contents of your CA into the exim.cert, after your actual certificate.
Probably a good idea to make sure you have a copy of everything elsewhere in case you make an error.
Dovecot and ProFtpd should also read it correctly, so dovecot no longer needs the ssl_ca option.
So for both cases, there is no need to make any changes to either the exim.conf or dovecot.conf(/etc/dovecot/conf/ssl.conf)
If you are using MacOS use:
sudo cp /usr/local/etc/openssl/cert.pem /etc/ssl/certs
after this Trust anchor not found error disappears
For those using zerossl.com certificates, drag and drop all certificates (as is) to their respective folders.
Cut and pasting text into existing files, may cause utf8 issues - depending upon OS, format and character spacings.