using https://support.comodo.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=3&nav=0,33
I generated "server.csr" to further create public certificate.
then i got two encrypted keys. I tried to make changes in the config.tcl accordingly but still the project-open application is pointing to local certificates.
particial code of config.tcl in which i made changes as follows:
ns_section ns/server/${server}/module/nsopenssl/sslcontexts
ns_param users "SSL context used for regular user access"
ns_section ns/server/${server}/module/nsopenssl/defaults
ns_param server users
ns_section ns/server/${server}/module/nsopenssl/sslcontext/users
ns_param Role server
ns_param ModuleDir ${serverroot}/etc/certs/
ns_param CertFile newcert.pem
ns_param KeyFile keyfile.pem
ns_param CADir ca
ns_param CAFile shipo_cert.txt
ns_param Protocols "SSLv2, SSLv3, TLSv1"
ns_param CipherSuite "ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP"
ns_param PeerVerify false
ns_param PeerVerifyDepth 3
ns_param Trace false
shipo_cert.txt is the certificate provided along with one more certificate
shipo_interm.txt.
I searched and tried my best but couldn't do it.
please help me out in this.
P.S. the project-open instance is already working with self signed certificate using openssl. but my organization wants it to run with the certificates they are providing
DF > Have you packed your private key and the signed public key,
DF > together with the CA keychain, into a .p12 file yet?
Victor > how to do that? please guide me through
This has been answered previously at Adding an intermediate certificates to a pkcs12 file in JBoss.
Assuming you have a certificate and private key for example.com:
openssl pkcs12 -export -in www-example-com.crt -inkey www.example.key -out www-example-com.p12
Be sure your certificate (www-example-com.crt above) has all the intermediate certificates required to build a valid chain; and not just the server's certificate. That means www-example-com.crt will have multiple PEM entries.
Test it with the following. ca.pem is your CA's root certificate.
echo -e "GET / HTTP/1.0\r\n" | openssl s_client -connect example.com:443 -CAfile ca.pem
You should finish with Verify return code: 0 (ok).
Related
What is the OCSP signing cert and key? Who should issue it?
So, if I have this:
Example Root Certificate Authority
Example Intermediate Certificate Authority
*.example.com (any domain)
I have setup the OCSP for the domain cert only, so the OCSP url is http://ocsp.example.com.
Now, I learnt to run an OCSP server with openssl:
openssl ocsp -host 127.0.0.5 -port 80 -rsigner "what_cert?.crt" -rkey "what_cert?.key" -CA "root_or_intermediate_which_one?.crt" -text -index certindex -ignore_err
127.0.0.5 points to ocsp.example.com
Now in that command, I learnt that those two are ocsp signing certs and keys:
openssl ocsp -host 127.0.0.5 -port 80 -rsigner "ocsp.crt" -rkey "ocsp.key" -CA "root_or_intermediate_which_one?.crt" -text -index certindex -ignore_err
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
should it be the ROOT or the INTERMEDIATE?
Now, the next question is what is the OCSP signing certificate and key? Who should issue it?
Finally, these are the questions, I have setup OCSP for the domain cert only, so let me get appropriate instructions for it:
What should be the -CA option? Should it be the ROOT or the INTERMEDIATE?
What is the OCSP signing certificate and key, and who should issue it? (And if you can help me, please also let me know how to issue it using OpenSSL)
Single OCSP server can provide OCSP services for multiple CAs. To distinguish the target CA the incoming request is for, OCSP implements a revocation profile (or configuration) where CA name ID or key ID (later is preferred) is used as profile identifier. And for each profile you need a signing certificate issued by same CA as referenced by profile identifier.
In your example, you have two CAs for which you may want to create OCSP revocation profiles:
Root CA:
openssl ocsp -host 127.0.0.5 -port 80 -rsigner "ocsp_sig_root.crt" -rkey "ocsp_sig_root.key" -CA "root.crt" -text -index certindex -ignore_err
where ocsp_sig_root.crt is the OCSP signing certificate signed by root CA (AKI extension in signing cert MUST match SKI in root.crt file). ocsp_sig_root.key is a key associated with ocsp_sig_root.crt.
Intermediate CA:
openssl ocsp -host 127.0.0.5 -port 80 -rsigner1 "ocsp_sig_subca.crt" -rkey1 "ocsp_sig_subca.key" -CA1 "subca.crt" -text -index1 certindex1 -ignore_err
where ocsp_sig_subca.crt is the OCSP signing certificate signed by intermediate CA (AKI extension in signing cert MUST match SKI in subca.crt file). ocsp_sig_subca.key is a key associated with ocsp_sig_subca.crt. You most likely will want only this. There is very little value in implementing OCSP for root CAs since their cert issuance/revocation is extremely low and CRL is more efficient.
That is, OCSP will have separate signing certificate for each CA the OCSP serves.
I have an issue with the server rejecting the client certificate in the handshake if I issue openssl call with just the cert (with chain) and private key.
This issue goes away if I also set the cafile param and point it to the same file as the cert.
It seems as if openssl cannot construct the chain without the cafile input even if the information is already in the cert input. I wonder if you guys had experience with this. I just find it a bit odd.
To summarize, this works:
sudo openssl s_client -connect <ip>:<port> -cert cert_with_chain.pem -key privkey.pem -CAfile cert_with_chain.pem
This doesn't work (Server reject with "null cert chain"):
sudo openssl s_client -connect <ip>:<port> -cert cert_with_chain.pem -key privkey.pem
Open SSL version:
OpenSSL 1.0.2k-fips 26 Jan 2017
The problem is not that "openssl cannot construct the chain without the cafile" but that it wasn't the intention in the first place to do so. The intended behavior is well documented in man s_client:
-cert certname The certificate to use, if one is requested by the server.
-CAfile file A file containing trusted certificates to use during server authentication and to use when attempting to build the client
certificate chain.
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.
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.
The Dropwizard example project has a single certificate without intermediate certificate and the HTTPS configuration doesn't mention anything regarding intermediate certs. Is it possible to configure Dropwizard to deliver intermediate certificates?
You should be able to add the intermediate certificate to the key store that you use for your certificate. To do that when you add the private key you should be able to add a chain of the signed public key with the intermediate certificate. The intermediate certificates should not be added by them selves The intermediate certificate should then also be sent to the client.
Dropwizard uses Jetty 9. From the Jetty 9 documentation:
If you have a chain of certificates, because your CA is an
intermediary, build the PKCS12 file as follows:
$ cat example.crt intermediate.crt [intermediate2.crt] ... rootCA.crt > cert-chain.txt
$ openssl pkcs12 -export -inkey example.key -in cert-chain.txt -out example.pkcs12
The order of certificates must be from server to rootCA, as per
RFC2246 section 7.4.2.
I would not include the root CA in the chain because it should be already known to the client.
OpenSSL will ask for an export password. Enter something and remember it for the configuration. The documentation includes further steps to convert the PKCS12 keystore to a JKS one, but that’s not required (PKCS12 works fine on Java 8u261).
Then configure the connector in your Dropwizard configuration file with the filename and password you used:
server:
applicationConnectors:
- type: h2c
port: 80
- type: h2
jceProvider: Conscrypt
port: 443
keyStorePath: example.pkcs12
keyStorePassword: foo
You can verify your configuration using OpenSSL:
openssl s_client -connect localhost:443
The section Certificate chain should show entries for your server certificate and the intermediate CAs.