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.
Related
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.
I am trying to secure my eXist-db app, which means the only port I want to leave open should be 8443 (for using WebDAV and admin app). This is the basic secure port eXist-db have open since the installation. It uses self-signed certificate. I have no problem with replacing default certificate with a new one but the problem is I am not able to do that with CA signed certificate.
I tried:
sudo rm eXist-db/tools/jetty/etc/keystore
cat ServerCertificate.crt Alpiro-TrustProvider-IntermediateCA.crt Root.cer > cert-chain.txt
I cleaned bad ends of lines and verified every certificate starts on a new line.
openssl pkcs12 -export -inkey my-app.key -in cert-chain.txt -out my-app.pkcs12
keytool -importkeystore -srckeystore my-app.pkcs12 -srcstoretype PKCS12 -destkeystore eXist-db/tools/jetty/etc/keystore
After restart, I checked the connection with: openssl s_client -connect xx.xx.xxx.xxx:8443 and everything seems fine. I can see there is my trusted certificate and the connection (handshake) simply works. However, browsers still claim it is not a trusted connection.
When I try to check something over https via XQuery, it throws:
java.security.cert.CertificateException: No subject alternative names matching IP address xx.xx.xxx.xxx found …
The solution is quite trivial. The problem was I had been trying to access the site via IP, not via fully qualified domain name. Certificates are associated with domain names, not IPs!
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).
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 !