I have created a SSl certificate using these commands:
openssl genrsa -out kc_ca-key 2048
openssl req -new -out san_domain.csr -key kc_ca-key -config openssl.cnf
openssl x509 -req -days 3650 -in san_domain.csr -signkey kc_ca-key -out kc_ca-cert -extensions v3_req -extfile openssl.cnf
openssl.cnf file contains the common name, country name, subject alternative name and all such information.
In browser, I am able to connect securely after importing this certificate but when i run curl command with same certificate, i get the following error:
NSS error -8156 (SEC_ERROR_CA_CERT_INVALID)
* Issuer certificate is invalid.
* Closing connection 0
curl: (60) Issuer certificate is invalid.
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
How to resolve this error
There is not enough information to determine what your problem is.
I am making the following assumptions:
You sent the certificate request (CSR) to a CA provider and got a certificate back.
You setup some sort of web server with that certificate
I am also assuming that you used a "Windows" web browser like IE or Chrome that uses the windows certificate store to test the certificate.
The CA that signed your certificate is a well known CA that has there root certificates in all the common CA Lists.
If the above is true and a web browser like Firefox (that uses it's internal CA list) fails it's because the web server is using a certificate without any intermediate certificates.
You need to go find the intermediate certificates for your CA signed certificate, combine them into a certificate chain and setup your web server with this certificate chain. The details of how to do this will depend on your web server.
Once the web server is setup with a correct certificate chain then your curl command (and firefox) should work fine.
The reason that windows works fine is because windows keeps a list of common intermediate certificates that it can verify a certificate chain with. A openssl based client doesn't, so the intermediate certificates have to come from the SSL socket server (e.g. web server) down to the client to be able to verify the certificate chain back to a trusted root certificate in the client CA list.
Related
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.
On my Github enterprise when I install the SSL certificate with the key its displaying an error message:
"Github ssl cert The certificate is not signed by a trusted
certificate authority (CA) or the certificate chain is missing
intermediate CA signing certificates."
I was given from our certification authority team 4 certificates.
SSL certificate : github.pem
A set of 3 CA certificates : root, subca and subca2
On my Github enterprise management console, it needs 2 entries
A x509 SSL certificate
Unencrypted key
I have tried github.pem key alone and with different combination by concatenating CA certificates, but its failing always with the same error.
Is there a pattern to concatenate the certificate?
Any clue how i can resolve this?
Thanks in advance.
Please abide the following steps to add 3 certificates to your .pem file:
Open your domain certificate pem file in Notepad ++.
Add intermediate (DigiCertCA2.pem) certificate under Domain certificate.
Add root certificate (TrustedRoot.pem) to your domain certificate.
Save the .pem file that have the following 3 certificates (domain , intermediate, root).
Upload the modified certificate.pem file and the private key.
click on Save Settings.
I had the same issue.
When trying to load the PEM and Key files to GitHub Enterprise I got the same message. The cert was created using the exact same methods as I have done before, but was failing.
Github ssl cert The certificate is not signed by a trusted certificate authority (CA) or the certificate chain is missing intermediate CA signing certificates.
Steps I took:
Created a cert for the server (webserver with Private Key)
Exported from my users personal store (PFX including all certs in the path and export all extended properties)
C:\OpenSSL-Win64\bin> openssl.exe pkcs12 -in git_key_included.pfx -nocerts -out priv-key.pem -nodes
C:\OpenSSL-Win64\bin> openssl.exe pkcs12 -in git_key_included.pfx -nokeys -out cert.pem
C:\OpenSSL-Win64\bin> openssl rsa -in priv-key.pem -out server.key
I eventually figured it out by opening the PEM using Notepad++. The openssl commands work fine on the old exported cert, but swap around the ordering of the certs on the new exported cert. The broken cert had:
Primary SSL certificate
Root certificate
Intermediate certificate
Instead of the correct ordering of:
Primary SSL certificate
Intermediate certificate
Root certificate
So I swapped them around and it worked.
I do have private key(my_ca.key) and public key(my_cert.crt) which is signed by DigiCert. Now I want to generate the SSL certificate (version 3) and sign it by my private key . Here is the way I tried to do that. But when I export into keychain (Mac OS X). I have been getting error like this "This certificate has an invalid issuer keychain". No idea how to solve this. Here my_cert.crt is extended from DigiCert High Assurance CA-3 and that one extended from DigiCert High Assurance EV Root CA. Also added DigiCert High Assurance CA-3, DigiCert High Assurance EV Root CA into keychain. It shows my_cert.crt is valid. How would be getting this kind of error.
######### Initialization
SSL_SUBJ="/C=LK/ST=Colombo/L=Colombo/O=wso2/OU=laptop/CN=mdm.go.com"
########SSL Certificate
echo "\nGenerating SSL Certificate >>>>>> START"
openssl genrsa -out ia.key 4096
openssl req -new -key ia.key -out ia.csr -subj "$SSL_SUBJ"
openssl x509 -req -days 365 -in ia.csr -CA my_cert.pem -CAkey my_ca.pem -set_serial 765644787 -out ia.crt -extensions v3_ca -extfile ./openssl.cnf
echo "\nGenerating SSL Certificate >>>>>> END \n"
openssl pkcs12 -export -out ia.p12 -inkey ia.key -in ia.crt -CAfile my_cert.pem -name sslcert -passout pass:password
Note: added custom entry in /etc/hosts mapping IP address to SSL certificate CN and for testing server and client are in the same machine.
Download
https://developer.apple.com/certificationauthority/AppleWWDRCA.cer
and double-click to install to Keychain.
Select "View" -> "Show
Expired Certificates" in Keychain app.
Confirm "Certificates" category is selected.
Remove expired Apple Worldwide Developer Relations Certificate Authority
certificates from "login" tab and "System" tab.
Here's Apple's answer.
Thanks for bringing this to the attention of the community and
apologies for the issues you’ve been having. This issue stems from
having a copy of the expired WWDR Intermediate certificate in both
your System and Login keychains. To resolve the issue, you should
first download and install the new WWDR intermediate certificate (by
double-clicking on the file). Next, in the Keychain Access
application, select the System keychain. Make sure to select “Show
Expired Certificates” in the View menu and then delete the expired
version of the Apple Worldwide Developer Relations Certificate
Authority Intermediate certificate (expired on February 14, 2016).
Your certificates should now appear as valid in Keychain Access and be
available to Xcode for submissions to the App Store.
You can also check on https://forums.developer.apple.com/thread/37208
For more detail refer https://developer.apple.com/support/certificates/expiration/
I have got a simple solution for this problem.
Select the certificate in keychain right click it. There you will see the option "GetInfo" click it and select "Trust" option. Select the option When using this certificate to "Always trust". That's all - this certificate will be marked as trusted for your account.
Normally all X.509 certificates in certificate chain except the last one are CA certificates. The first certificate in chain is called root CA (in your case DigiCert High Assurance EV Root CA), then other CA certificates in issuer chain (if any) are intermediate CAs and the last one is End Entity (not CA). I don't think you can issue new SSL certificate issued by non-CA certificate. So you can use my_cert.crt signed by DigiCert as SSL certificate but you cannot issue your own using my_ca.key.
I have requested a class 1 certificate from StartSSL and installed it in Weblogic 10.0.1 (see screenshots).
The browsers (Chrome & IE9 on Windows 7, IE8 on XPSP3) still give a certificate error (see screenshots).
I think the StartSSL root certificate is available in several browsers (see here). Please advise.
StartSSL Class 1 certificates are signed by a intermediate CA, which is signed by the StartCom Root CA. For your browser to trust this certificate, it needs to know the trust chain up to the Root CA it already knows.
Your server needs to send the complete trust chain to the browser (minus the Root CA), so your browser can verify that your certificate is trusted.
See the StartSSL FAQ for more info.
Found the problem. I've imported the StartSSL certificate incorrectly in our keystore. Also, I've specified "weblogic" as alias in the Weblogic console which is not the certificate but the public/private key pair. I'm using Portecle to edit the keystore.
When I've noticed that I was probably using the wrong alias I've changed it to the alias of the certificate. This resulted in a Weblogic error:
Inconsistent security configuration, weblogic.management.configuration.ConfigurationException: No identity key/certificate entry was found under alias startssl-hostname in keystore keystore_StartSSL on server servername
In the end I've followed these steps to pack the certificate and private key in one PKCS#12 keystore. I've then imported that keystore into our java keystore using Portecle:
Export the "weblogic" public/private key using Portecle as a PKCS#12 keystore.
Extract the private key from this keystore using openssl:
openssl pkcs12 -in weblogic.p12 -nocerts -out privatekey.pem
Package the certificate and private key as a PKCS#12 keystore (cert.p12) using openssl:
openssl pkcs12 -export -in cert.cer -inkey privatekey.pem -out cert.p12 -name cert -CAfile ca.pem -caname root
Import cert.p12 file into our java keystore using Portecle using "cert" as alias.
Changed the Weblogic configuration to use the "cert" alias with the correct passphrase.
And it worked!
PS: I've added the JCE unlimited strength policy along the way since Portecle complained about this at one point.
Generally the trust store and keystore would be separate, but it will not cause the error above.
If your browser does not trust the CA then you will receive the above error. You need to add the root CA to your browser. You can check the certs that your browser supports.
Eg for IE -> Tools -> Internet Options -> Content -> Certificates -> Trusted Root CA
Assuming you need to import this into one or two browsers, its not a big deal. But if you need to do this across the enterprise (meaning 100 or 1000 of browsers), you will need help from your desktop support team !
I'm trying to connect to a web service (not under my control) configured to authenticate users via SSL client certs. I have a valid certificate in PKCS12 format containing the client certificate and associated private key. The certificate is issued by a CA accepted by the web service provider.
Installing the certificate and trying to access the restricted area in various browsers gives the following results:
IE6 - Works fine and I can retrieve the WSDL
IE7 - Prompts for the certificate but then fails with a 403.7 from the server
Firefox3 - Set to ask, but no prompt and fails with a 403.7
Safari 4 - Certificate is installed in the Keychain, but no prompt and a 403.7
Also, trying to access the web service programmatically (Java) fails with the same 403.7 error code.
Strange that this works in IE6 but in no other browser, what am I missing? Do I need to include the full CA certificate chain in the PKCS12 file?
Any help would be greatly appreciated.
This really works! If you're confused by the -inkey and -in options, they are the private key and certificate from the p12 file. You can convert the p12 file to pem format with:
openssl pkcs12 -in file.p12 -clcerts -out file.pem
and use the above command with "-in file.pem" only.
Also, you can import the root CA cert into your trusted certs store, here is the description how to do that: http://gagravarr.org/writing/openssl-certs/others.shtml#ca-openssl, and then you don't have to manually copy the certificates. After installing the cert use the command above without the "-CAfile chain.pem".
Ok, got this working. The answer is yes, I did need to include all intermediary CA certs in the PKCS12 file. I concatenated all the intermediary CA certs plus the Root CA cert in the file "chain.pem" then executed the following command:
openssl pkcs12 -export -chain -CAfile chain.pem -in cert.pem -inkey key.pem -out cert.p12