I have a need to use a self-signed (or unsigned) certificate as a certificate for an HTTPS listener for an inbound endpoint to one of my flows. I have tried several methods to generate certificates, but I always get an error when the listener attempts to read a request:
javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
Google seems to think that the bad_certificate message has something to do with the trust store. I continue to see the same error with or without the mule tls-server configuration which is supposed to define the trust store.
I've used several different mechanisms to create the certificate:
The method using keytool in the mule documentation for the HTTPS Transport
A method described for weblogic, using keytool
A method described for Apache, using openssl, which I then imported into a java keystore using keytool
A variety of other mechanisms that are mostly variations of the above.
I have tried both with and without the tls-server and tls-client elements configured, all as described in the mule documentation.
I am at my wit's end trying to determine what key types are acceptable to Mule, and what the root cause of the issue is. Any advise is appreciated.
My configurations and error logs follow (omitting various boilerplate content)
mule-config.xml
<https:connector name="connectorName">
<!-- only one key, alias 'mule' -->
<https:tls-key-store path="/opt/mule/keys/keystore.jks" keyPassword="thePassword" storePassword="thePassword"/>
<!-- I've also tried the following, same error occurs both with or without this parameter -->
<https:tls-server path="/opt/mule/keys/keystore.jks storePassword="thePassword"/>
</https:connector>
<flow name="theFlow">
<https:inbound-endpoint host="0.0.0.0" port="8081" connector-ref="connectorName"/>
<!-- stuff: not important, works with http -->
</flow>
This configuration loads correctly, but then when I attempt to post a request using the same method that works with HTTP (but using https:// instead) I get the following error, and no response back (not a 500 error, or anything, connection is just closed). This specific run is from the key I generated using the instructions on the mulesoft documentation for HTTPS Transport, but it is not any different from the error I get using any other method.
Error Listing
[ERROR] org.mule.exception.DefaultSystemExceptionStrategy - Caught exception in Exception Strategy: Received fatal alert: bad_certificate
javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1822)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1004)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.waitForClose(SSLSocketImpl.java:1571)
at com.sun.net.ssl.internal.ssl.HandshakeOutStream.flush(HandshakeOutStream.java:103)
at com.sun.net.ssl.internal.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:689)
at com.sun.net.ssl.internal.ssl.ServerHandshaker.sendChangeCipherAndFinish(ServerHandshaker.java:1279)
at com.sun.net.ssl.internal.ssl.ServerHandshaker.clientFinished(ServerHandshaker.java:1239)
at com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:225)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:943)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1188)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:818)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:50)
at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
at org.mule.transport.http.HttpServerConnection.readLine(HttpServerConnection.java:219)
at org.mule.transport.http.HttpServerConnection.readRequest(HttpServerConnection.java:185)
at org.mule.transport.http.HttpMessageReceiver$HttpWorker.run(HttpMessageReceiver.java:155)
at org.mule.work.WorkerContext.run(WorkerContext.java:310)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Finally, thanks for your time reading this far.
UPDATE
I've started to get a different stack trace, but the same error. The change? The key and the keystore now have different passwords.
javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1822)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1004)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:820)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:50)
at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
at org.mule.transport.http.HttpServerConnection.readLine(HttpServerConnection.java:219)
at org.mule.transport.http.HttpServerConnection.readRequest(HttpServerConnection.java:185)
at org.mule.transport.http.HttpMessageReceiver$HttpWorker.run(HttpMessageReceiver.java:155)
at org.mule.work.WorkerContext.run(WorkerContext.java:310)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
UPDATE 2
I added the key to the .../jre/lib/security/cacerts file as a trusted certificate. No change.
The method for creating a self-signed certificate shown in the Mule doc works: I've used it several times. I tried it again and it works with your configuration, except that I removed https:tls-server, which is useless.
Here are the steps I followed:
Create the keystore with: keytool -genkey -alias mule -keyalg RSA -keystore keystore.jks (I used "thePassword" for both the keystore and the key passwords).
Configured Mule like this:
<https:connector name="connectorName">
<https:tls-key-store
path="...path.../keystore.jks"
keyPassword="thePassword" storePassword="thePassword" />
</https:connector>
<flow name="theFlow">
<https:inbound-endpoint host="0.0.0.0" port="8081"
connector-ref="connectorName" />
<set-payload value="w00t" />
</flow>
Tested with:
$ curl -vk https://localhost:8081
* About to connect() to localhost port 8081 (#0)
* Trying 127.0.0.1... connected
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-RSA-AES256-SHA
* Server certificate:
* subject: C=Unknown; ST=Unknown; L=Unknown; O=Unknown; OU=Unknown; CN=Unknown
* start date: 2013-05-15 18:20:34 GMT
* expire date: 2013-08-13 18:20:34 GMT
* common name: Unknown (does not match 'localhost')
* issuer: C=Unknown; ST=Unknown; L=Unknown; O=Unknown; OU=Unknown; CN=Unknown
* SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: localhost:8081
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Wed, 15 May 2013 11:24:24 -0700
< Server: Mule Core/3.4.0
< X-MULE_SESSION: rO0ABXNyACNvcmcubXVsZS5zZXNzaW9uLkRlZmF1bHRNdWxlU2Vzc2lvbi7rdtEW7GGKAwAEWgAFdmFsaWRMAA1mbG93Q29uc3RydWN0dAAmTG9yZy9tdWxlL2FwaS9jb25zdHJ1Y3QvRmxvd0NvbnN0cnVjdDtMAAJpZHQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAD3NlY3VyaXR5Q29udGV4dHQAJ0xvcmcvbXVsZS9hcGkvc2VjdXJpdHkvU2VjdXJpdHlDb250ZXh0O3hwAXB0ACRhYjcwZTY0OS1iZDhjLTExZTItOWU5Yy1mZjdmMDIxMmE5MmZwc3IAJWphdmEudXRpbC5Db2xsZWN0aW9ucyRTeW5jaHJvbml6ZWRNYXAbc/kJS0s5ewMAAkwAAW10AA9MamF2YS91dGlsL01hcDtMAAVtdXRleHQAEkxqYXZhL2xhbmcvT2JqZWN0O3hwc3IAJG9yZy5tdWxlLnV0aWwuQ2FzZUluc2Vuc2l0aXZlSGFzaE1hcJ3R2e9nRc4AAwAAeHB3DD9AAAAAAAAQAAAAAHhxAH4ACXh4
< X-MULE_ENCODING: UTF-8
< LOCAL_CERTIFICATES: [Ljava.security.cert.X509Certificate;#1c5e22a
< Content-Type: text/plain
< Content-Length: 4
< Connection: close
<
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
w00t
Hopefully this helps someone else. I'm running Mule EE 3.5.0 with jdk1.6.0_45. The command listed above would not generate a compatible keystore. The keystore was fine when running in studio but would not work on the standalone ESB.
I reviewed the keystore used on the mule-security-example3.5.0 application and found differences. I used KeyStore Explorer to create a keystore that had these attributes
Size: 1024
Version: 1
Alg: MD5 with RSA
Perhaps there is something off with the configuration on my instance of Mule EE; if someone could point me in the right direction I would appreciate it. Using a key with the above attributes will work with EE 3.5.0 which was downloaded from the customer portal this week.
Related
I have been given the following files for setting up TLS for a website running on the domain example.com:
example.com.key (containing the private key)
example.com.cer (containing one certificate)
intermediate_example.com.crt (containing two certificates)
example.com.csr (containing one certificate request)
I'm using Traefik to host the site, and I've configured Traefik like so in the dynamic.yml config:
tls:
certificates:
- certFile: "certs/example.com.cer"
keyFile: "certs/example.com.key"
stores:
- default
Doing so resulted in a website I could access via Chrome and Firefox, but whenever trying a request with curl (or any program using its libraries), I get the following error:
➜ ~ curl -v https://test.example.com/
* Trying xxx.xxx.xxx.xxx:443...
* Connected to test.example.com (xxx.xxx.xxx.xxx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
Why is this working in browsers, but not via curl?
I have ensured that the ca-certificates package is installed on the host, and even when I download the most recent CA bundle and use curl --cacert cacert.pem …, it does not work.
What am I missing here?
The reason it does not work is that the intermediate certificate is missing in what Traefik is sending to the client.
The browsers can work around this using the Authority Information Access mechanism, and even macOS does this, fetching the missing information out-of-band, thereby allowing you to access the site normally. Some background is given here.
This is obviously a configuration error on the server. To fix it, at least for Traefik, you can concatenate everything into one .pem file. You don't need to add the CSR file here:
cat example.com.key example.com.cer intermediate_example.com.crt > cert.pem
Then, specify the same file twice in Traefik's config:
tls:
certificates:
- certFile: "certs/cert.pem"
keyFile: "certs/cert.pem"
stores:
- default
This is also mentioned in this discussion on the Traefik community board.
Running this command inside wsl 2 windows delivers the below output.
Can anyone explain why there are mixed TLSv1.3 and TLSv1.2 IN and OUT and is this a potential reason as to why its unable to get local issuer certificate.
The Windows host OS is Enterprise
I have installed ca-certificates and ran update-ca-certificates
curl -v https://google.com:443/
* Trying 172.217.169.78...
* TCP_NODELAY set
* Connected to google.com (172.217.169.78) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
Are you using a network connection subject to monitoring or 'protection' such as antivirus, like one provided by a business, organization or school? If so you are probably getting a fake cert/chain from the interceptor.
Try openssl s_client -connect google.com:443 and look at the s:and i: lines under Certificate chain. (Many hosts today require SNI to respond correctly and if your OpenSSL is below 1.1.1 you need to add -servername x to provide SNI, but google is not one of them, and anyway since your curl is at least trying 1.3 it cannot be OpenSSL below 1.1.1.)
Or, if connecting from Chrome, Edge or IE (but maybe not Firefox) on the host Windows works normally, doubleclick the padlock and look at the cert chain to see if it leads to GlobalSign Root CA (as the real google does) or something else (like e.g. BlueCoat); if the latter the interceptor's root cert is installed in your host Windows store, but not the WSL system. You can export the cert from the host browser and put it in a file, and either use it manually with curl --cacert $file, or import it to the WSL system's truststore, but that depends on what system you are running in WSL which you didn't say.
Added: the mixture of TLS 1.3 and 1.2 in the logging info is probably because 1.3 uses the same record header version as 1.2 as a transition hack, with an extension that indicates it is really 1.3 only in the two Hello messages, and the callback probably doesn't deal with this.
Turns out there were missing certificates that once provided and installed it worked fine
Recently I've been evaluating different API Gateway (API GW) options for the IoT-based project. The purpose of this was to find a good enough solution for performing Mutual TLS (mTLS) authentication of the devices and API GW.
Most of the solutions I've tried out seem to perform mTLS during the TLS handshake as nicely depicted here. So this is what I understand OSI Layer 4 (TCP/IP) authentication method.
However, the Kong API Gateway seem to do it at OSI Layer 7 (Application). Basically, no client auth during the TLS handshake phase, and rather application layer validates the peer certificate. Hence it's able to send the response with 401 status and some payload (which is not possible, if TLS handshake fails). Example
√ poc-mtls-local-env % make test-fail-wrong-cert master
curl -v --cacert certs/gen/ca-chain.crt \
--key certs/gen/device.key \
--cert certs/gen/device.crt \
https://mtls.auth.local.com/echo
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to mtls.auth.local.com (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: certs/gen/ca.crt
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS handshake, CERT verify (15):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=NY; L=NYC; O=Sample; OU=UDS; CN=local.com
* start date: Jul 29 12:10:25 2021 GMT
* expire date: Jul 29 12:10:25 2022 GMT
* subjectAltName: host "mtls.auth.local.com" matched cert's "mtls.auth.local.com"
* issuer: C=US; ST=NY; O=Sample; OU=UDS; CN=Sample Intermediate CA; emailAddress=it#sample.com
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fc0dd808200)
> GET /echo HTTP/2
> Host: mtls.auth.local.com
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 401
< date: Tue, 10 Aug 2021 06:46:13 GMT
< content-type: application/json; charset=utf-8
< content-length: 49
< x-kong-response-latency: 4
< server: kong/2.4.1.1-enterprise-edition
<
* Connection #0 to host mtls.auth.local.com left intact
{"message":"TLS certificate failed verification"}* Closing connection 0
We can clearly see that request goes past the TLS handshake successfully, and the application layer forms 401 response with {"message": "TLS certificate failed verification"}.
This made me think of the following questions:
Formally speaking, can it also be called mTLS what Kong does here?
Are there any potential pitfalls with such an approach?
Most of the solutions I've tried out seem to perform mTLS during the TLS handshake as nicely depicted here. So this is what I understand OSI Layer 4 (TCP/IP) authentication method.
Since TLS is above layer OSI layer 4 the authentication is also above layer 4. But OSI layers aside (which don't sufficiently match today's reality above layer 4 anyway) you essentially ask at what stage the mutual authentication happens.
Mutual authentication in TLS happens in two stages: requesting the clients certificate and validating that the certificate matches the requirements. Requesting the certificate is always done inside the TLS handshake, although it does not need to be the initial TLS handshake of the connection.
Validating the certificate can be done inside the TLS handshake, outside of it or a combination of both. Typically it is checked inside the handshake that the certificate is issued by some trusted certificate authority, but further checks for a specific subject or so might be application specific and will thus be done after the TLS handshake inside the application. But it might also be that the full validation is done inside or outside the TLS handshake.
Accepting any certificates inside the TLS handshake and validating the certificate then outside the handshake only, has the advantage that one can return a useful error message to the client inside the established TLS connection. Validation errors inside the TLS handshake instead result in cryptic errors like handshake error alerts or just closing the connection, which are not that helpful to debug the problem.
I purchased, this morning SLL certificates from Comodo (via DNSimple) and have been trying to get it to work on my domain. Sigh. Not having a lot of success.
The certificates I have are listed in the email from Comodo as:
Root CA Certificate - AddTrustExternalCARoot.crt
Intermediate CA Certificate - COMODORSAAddTrustCA.crt
Intermediate CA Certificate - COMODORSADomainValidationSecureServerCA.crt
Your EssentialSSL Certificate - www_XXXXXXX_com.crt
Following the blog post by Ryan McGeary I have ensured that I do the following putting the cry files in the reverse order from that suggested in the email:
cat www_XXXXXXXX_com.crt COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > www_XXXXXXXX_com-bundle.pem
I downloaded the key from DNSimple too and saved that to a file called server.key.
When I add the certificates to Heroku I use the following command:
heroku certs:add www_XXXXXXXX_com-bundle.pem server.key
Which seemed to report no errors in the following:
Resolving trust chain... done
Adding SSL Endpoint to XXXXXXXX... done
XXXXXXXX now served by XXXXXXXX.herokussl.com
Certificate details:
Common Name(s): XXXXXXXX.com
www.XXXXXXXX.com
Expires At: 2015-09-28 23:59 UTC
Issuer: /OU=Domain Control Validated/OU=EssentialSSL/CN=www.XXXXXXXX.com
Starts At: 2014-09-28 00:00 UTC
Subject: /OU=Domain Control Validated/OU=EssentialSSL/CN=www.XXXXXXXX.com
SSL certificate is verified by a root authority.
When I do heroku certs, I get the following:
Endpoint Common Name(s) Expires Trusted
------------------------- ------------------------------ -------------------- -------
XXXXXXXXXXX.herokussl.com www.XXXXXXXX.com, XXXXXXXX.com 2015-09-28 23:59 UTC True
Following the instruction from Heroku I try the certificate with:
curl -kvI https://www.XXXXXXXX.com
Heroku says I should expect output similar to:
$curl -kvI https://www.example.com
* About to connect() to www.example.com port 443 (#0)
* Trying 50.16.234.21... connected
* Connected to www.example.com (50.16.234.21) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
* subject: C=US; ST=CA; L=SF; O=SFDC; OU=Heroku; CN=www.example.com
* start date: 2011-11-01 17:18:11 GMT
* expire date: 2012-10-31 17:18:11 GMT
* common name: www.example.com (matched)
* issuer: C=US; ST=CA; L=SF; O=SFDC; OU=Heroku; CN=www.heroku.com
* SSL certificate verify ok.
I don't get anything like that ...
* Adding handle: conn: 0x7fe62c004400
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fe62c004400) send_pipe: 1, recv_pipe: 0
* About to connect() to www.XXXXXXXX.com port 443 (#0)
* Trying 50.16.247.106...
* Connected to www.XXXXXXXX.com (50.16.247.106) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
* Server certificate: www.XXXXXXXX.com
* Server certificate: COMODO RSA Domain Validation Secure Server CA
* Server certificate: COMODO RSA Certification Authority
* Server certificate: AddTrust External CA Root
> HEAD / HTTP/1.1
> User-Agent: curl/7.30.0
> Host: www.XXXXXXXX.com
> Accept: */*
And this seems to suggest that when I try https://www.XXXXXXXX.com (my root address) I don't get any indication of the SSL.
Obviously something is wrong, but I have no idea what, or how to correct it. I've followed all the advice I can find online, but it all seems to be slightly different to the certificates I have received from Comodo. And I have no idea how to work this through to make the SSL certificate work.
Any help to resolve this would be excellent as it's really stumped me.
I've also ensured my DNS records for www.XXXXXXXX.com and XXXXXXX.com are pointing to the herokussl.com URL stated in the set up.
I've left this for 10 hours hoping it might "ripple through", but there is something wrong and I don't know what.
Thanks in advance for any help you might be able to give.
Simone was very helpful in checking that things seemed to be working as they should with regards to the installation of the certificate with Heroku. It would appear however that there was "mixed content" on each of my HTML pages which meant the "Protected" icons were not coming up in Safari (and were showing in a limited way in Firefox).
On changing all HTML content to be referenced with https:// rather than http:// gave me the required security for the whole page.
I also needed to add the following to my application.rb to get my Rails application to serve all pages securely:
config.force_ssl = true
Hope this comes in useful for other people!
i have one java program that connects to one server and interacts with that server and does (say hello world) simple task.
my java program is to interact with vmware esxi server. with the following code.
ServiceInstance si = new ServiceInstance(new URL("https://10.100.13.36/sdk"), "root", "teamw0rk", true)
true parameter indicates that the ignore certificate to true.
even it is a vmware interaction the library it is purely a problem with certificate.Because when i put false for ignore certificate. i got the general certificate expectation from the library files.
the program is as follows.
package com.vmware.vim25.mo.samples;
import java.net.URL;
import com.vmware.vim25.*;
import com.vmware.vim25.mo.*;
public class HelloVM
{
public static void main(String[] args) throws Exception
{
long start = System.currentTimeMillis();
ServiceInstance si = new ServiceInstance(new URL("https://10.100.13.36/sdk"), "root", "teamw0rk", false);
long end = System.currentTimeMillis();
System.out.println("time taken:" + (end-start));
Folder rootFolder = si.getRootFolder();
String name = rootFolder.getName();
System.out.println("root:" + name);
ManagedEntity[] mes = new InventoryNavigator(rootFolder).searchManagedEntities("VirtualMachine");
if(mes==null || mes.length ==0)
{
return;
}
VirtualMachine vm = (VirtualMachine) mes[0];
VirtualMachineConfigInfo vminfo = vm.getConfig();
VirtualMachineCapability vmc = vm.getCapability();
vm.getResourcePool();
System.out.println("Hello " + vm.getName());
System.out.println("GuestOS: " + vminfo.getGuestFullName());
System.out.println("Multiple snapshot supported: " + vmc.isMultipleSnapshotsSupported());
si.getServerConnection().logout();
}
}
the error is related to expecting the ssl certificate.
Exception in thread "main" java.rmi.RemoteException: VI SDK invoke exception:javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address 10.100.13.36 found
at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:182)
at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:124)
at com.vmware.vim25.ws.VimStub.retrieveServiceContent(VimStub.java:1521)
at com.vmware.vim25.mo.ServiceInstance.<init>(ServiceInstance.java:85)
at com.vmware.vim25.mo.ServiceInstance.<init>(ServiceInstance.java:69)
at com.vmware.vim25.mo.samples.HelloVM.main(HelloVM.java:16)
As i confirmed the program error is no relation to vmware and it is related to certificate.
the first step i have done is creating the jks file using the following command
c:/java/jre/bin>keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048
it creates the keystore.jks in the bin folder.
i have to understand how to refer this keystore.jks in the java program.(i am having less knowledge on this...sorry)
how to generate the certificate and what is the meaning of importing the certificate and exporting the certificate.
In my case do i need to import or export..
Initially i posted the question one person..
he answered as " At high level, you will need the server certificate into your keystore and include the keystore in the JVM parameter"
Please clarify my doubts and throw some light on this..
thank you.
The error you are getting is complaining that the host name in the URL (10.100.13.36) does not match the any of the server names contained in the server's SSL certificate.
CertificateException: No subject alternative names matching IP address 10.100.13.36 found
Can you retry using the actual server name in your URL request? You may need to use the fully qualified name of the server. As you need to match the name of the server that is contained in the SSL certificate that the server is using.
You can use the curl command to take a look at the server's certificate, for example:
curl -v https://10.100.13.36/sdk
Here's what Microsoft's SSL certificate contains:
C:\>curl -v https://www.microsoft.com
* About to connect() to www.microsoft.com port 443 (#0)
* Trying 64.4.11.20... connected
* Connected to www.microsoft.com (64.4.11.20) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: c:\tpf$\bin\curl-ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-MD5
* Server certificate:
* subject: C=US; ST=WA; L=Redmond; O=Microsoft Corporation; OU=MSCOM; CN=
www.microsoft.com
* start date: 2012-03-29 19:29:53 GMT
* expire date: 2014-03-29 19:29:53 GMT
* common name: www.microsoft.com (matched)
* issuer: DC=com; DC=microsoft; DC=corp; DC=redmond; CN=Microsoft Secure
Server Authority
* SSL certificate verify ok.
> GET / HTTP/1.1
Short answer:
First test using DNS name of the server instead of IP (long explanation here).
Second if you want to use the certificate, you will have to import the server certificate, not to generate one by yourself...
The certificate is used by Tomcat, not your client. See the Tomcat SSL documentation.
Try adding -dname CN=10.100.13.36 when you generate the certificate. I don't think you even need to use subject alternate names. The common name (CN) should be equal to the domain name you used in the URL to connect.