I have a website I am using to host redmine and several git repositories
This works perfectly for http, but I can't clone with https, i.e.
git clone http://mysite.com/git/test.git
works fine, but
git clone https://mysite.com/git/test.git
fails
The strange thing is that https seems to work for everything else I have tested. If I open
https://mysite.com/git/test.git
in a browser (tested in chrome and firefox), I get no errors or warnings. I can also
curl https://mysite.com/git/test.git
wget https://mysite.com/git/test.git
both of which work with no complaints or warnings.
Here is the verbose output from git:
$ GIT_CURL_VERBOSE=1 git clone https://user#mysite.com/test/test.git
Cloning into test...
Password:
* Couldn't find host mysite.com in the .netrc file; using defaults
* About to connect() to mysite.com port 443 (#0)
* Trying 127.0.0.1... * Connected to mysite.com (127.0.0.1) port 443 (#0)
* found 157 certificates in /etc/ssl/certs/ca-certificates.crt
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Closing connection #0
* Couldn't find host mysite.com in the .netrc file; using defaults
* About to connect() to mysite.com port 443 (#0)
* Trying 127.0.0.1... * Connected to mysite.com (127.0.0.1) port 443 (#0)
* found 157 certificates in /etc/ssl/certs/ca-certificates.crt
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Closing connection #0
error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://user\
#mysite.com/test/test.git/info/refs
fatal: HTTP request failed
Here is the verbose output from curl, with the personal info changed:
* About to connect() to mysite.com port 443 (#0)
* Trying 127.0.0.1... connected
* Connected to mysite.com (127.0.0.1) port 443 (#0)
* 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 DHE-RSA-AES256-SHA
* Server certificate:
* subject: C=US; <... cut my certs info ...>
* start date: 2011-10-18 00:00:00 GMT
* expire date: 2013-10-17 23:59:59 GMT
* subjectAltName: mysite.com matched
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO High-Assurance Secure Server CA
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.21.6 (x86_64-pc-linux-gnu) libcurl/7.21.6 OpenSSL/1.0.0e zlib/1.2.3.4 libidn/1.22 librtmp/2.3
> Host: mysite.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 18 Oct 2011 21:39:54 GMT
< Server: Apache/2.2.14 (Ubuntu)
< Last-Modified: Fri, 14 Oct 2011 03:20:01 GMT
< ETag: "8209c-87-4af39bb89ccac"
< Accept-Ranges: bytes
< Content-Length: 135
< Vary: Accept-Encoding
< Content-Type: text/html
< X-Pad: avoid browser bug
<
<p>Welcome to the mysite.com<p/>
* Connection #0 to host mysite.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
The only difference I can see is that git seems to be using an explicit CAfile while curl uses the whole directory? I'm new to ssl (at least on the admin side), so I'm not sure what this means or how I could configure git to work the same way as curl.
I am using git 1.7.5.4 and apache 2.2.14 on Ubuntu 10.04. I've tried cloning from 3 different linux hosts (including another account on the server itself), and nothing works.
I've also used the openssl tool to verify my cert on the server:
$openssl verify -purpose sslserver -CAfile chain.crt signed.pem
signed.pem: OK
This may be related to the bug https://bugs.maemo.org/show_bug.cgi?id=4953 but it seems different because I am not getting any warning or errors in any other program.
It may be worth mentioning that I am using gitolite and redmine_git_hosting using smart http to do authentication over https. I don't think any of this is at fault though, because the problem exists even if I just stick an otherwise working bare repo in /var/www and access it directly. Also, git over ssh (with and without gitolite) works.
Please let me know if you have any idea what might be wrong or if you'd like some more info. I'd really prefer to get ssl working properly, as opposed to forcing everyone to disable certificate checking in git, although that is a current workaround.
Thanks for reading this long post!
It turns out that this was a gnuTLS issue. gnuTLS is order sensitive, while openssl is not. I re-ordered the certificates in my intermediate cert file and the problem went away
XCondE's answer will address the problem, but turning off security warnings always feels like a bad idea. If you're running on an ubuntu box, then the issue may be that the CA certificate for your web server isn't in the /etc/ssl/certs/ca-certificates.crt file. I ran into this with a git server hosted on a web server with a SSL certificate signed by www.incommon.org.
You can add the intermediate certificate to your ca-certificates file, as follows:
wget http://cert.incommon.org/InCommonServerCA.crt
openssl x509 -inform DER -in InCommonServerCA.crt -out incommon.pem
cat /etc/ssl/certs/ca-certificates.crt incommon.pem > ca-certs2.crt
sudo cp /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt.bak
sudo cp ca-certs2.crt /etc/ssl/certs/ca-certificates.crt
There's a good discussion of what's going on behind the scenes here:
http://curl.haxx.se/docs/sslcerts.html
I encountered this error with one of my Comodo PositiveSSL certificates and was able to fix it by changing the order of the intermediate certificates.
After ordering the certificate, I was provided with the following files:
Root CA Certificate - AddTrustExternalCARoot.crt
Intermediate CA Certificate - COMODORSAAddTrustCA.crt
Intermediate CA Certificate - COMODORSADomainValidationSecureServerCA.crt
PositiveSSL Wildcard Certificate - STAR_mydomain_com.crt
Originally, the order of certificates in the .crt I was providing to Nginx was as follows:
PositiveSSL Wildcard Certificate - STAR_mydomain_com.crt
Intermediate CA Certificate - COMODORSAAddTrustCA.crt
Intermediate CA Certificate - COMODORSADomainValidationSecureServerCA.crt
However, I reversed the order of the last two certificates and Git no longer throws verification errors.
git uses gnutls for this stuff, which requires the CA be specified. This can be done with per-respository with:
git config http.sslcapath <path to CA directory>
OR
git config http.sslcainfo <path to CA cert>
You can also specify --system or --global.
The problem may be that you didn't configure correctly Apache
You may have to add your server name to the Apache configuration file
/etc/apache2/sites-enabled/default-ssl.conf, e.g.:
ServerName demo.personalserver.com
From: https://www.progclub.org/blog/2014/09/03/gnutls_handshake-failed-using-git/#comment-96924
export GIT_SSL_NO_VERIFY=1
From http://blog.breadncup.com/2011/06/09/skip-git-ssl-verification/
WARNING: as some people mentioned, this disables verification, leaving you open to a sleuth of security issues. You shouldn't rely on it long-term but, in a pinch, it will get the job done.
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
I need to do curl uploading behind company proxy. and I've getting the following two type of problems depending on the site that I try,
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
curl: (60) SSL certificate problem: unable to get local issuer certificate
Here are the details:
Case 1:
. . .
< HTTP/1.1 200 Connection established
< Proxy-agent: CCProxy
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* 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):
* CONNECT phase completed!
* CONNECT phase completed!
* error:1408F10B:SSL routines:ssl3_get_record:wrong version number
* Closing connection 0
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
Case 2:
$ curl -vX POST -d "userId=5&title=Hello World&body=Post body." https://jsonplaceholder.typicode.com/posts
Note: Unnecessary use of -X or --request, POST is already inferred.
* Uses proxy env variable https_proxy == 'http://10.xx.xx.xx:808/'
* Trying 10.xx.xx.xx:808...
* TCP_NODELAY set
* Connected to 10.xx.xx.xx port 808 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to jsonplaceholder.typicode.com:443
> CONNECT jsonplaceholder.typicode.com:443 HTTP/1.1
> Host: jsonplaceholder.typicode.com:443
> User-Agent: curl/7.68.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
< Proxy-agent: CCProxy
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* 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):
* CONNECT phase completed!
* CONNECT phase completed!
* 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
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
The problem is not the above CCProxy, but our company is using the Zscaler transparent proxy which is intercepting SSL requests with its own certificate.
Is there any way to fix it pls?
$ curl --version
curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1g zlib/1.2.11 brotli/1.0.7 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.8.0 nghttp2/1.40.0 librtmp/2.3
Release-Date: 2020-01-08
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux bullseye/sid
Release: testing
Codename: bullseye
Step 1 in both options will extract the Zscaler certificates.
OPTION 1 Direct curl
Download the certificates (all certificates are included in a single file)
Execute the curl command passing the certificateS you want to use.
# 1
openssl s_client -showcerts \
-connect jsonplaceholder.typicode.com:443 </dev/null 2>/dev/null \
| sed -n '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' > typicode.crt
# 2
curl --cacert typicode.crt -v \
-d "userId=5&title=Hello World&body=Post body." \
https://jsonplaceholder.typicode.com/posts
OPTION 2 (installer script)
In case the curl command is executed by an installer you don't have control, then, update your certificates:
Extract the certificates from server (use the FQDN or IP and PORT, i.e: jsonplaceholder.typicode.com:443)
Move the XXX.crt certificate to your certificates directory
Update certificates
Execute installation script
# 1
openssl s_client -showcerts \
-connect jsonplaceholder.typicode.com:443 </dev/null 2>/dev/null \
| sed -n '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' > typicode.crt
# 2
sudo mv typicode.crt /usr/local/share/ca-certificates/
# 3
sudo update-ca-certificates
# 4 execute your installer script
Bonus
In case you need/want to get the Zscaler certificates only, get the IP from: https://ip.zscaler.com
openssl s_client -showcerts -servername server -connect 165.225.216.33:443 > </dev/null 2>/dev/null | sed -n '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' | grep -m1 -B-1 -- '-----END CERTIFICATE-----' > zscaler.crt
UPDATED (11/19/21):
Adding option 1, when is a direct curl and no need of install the certificates.
Optimized the command for extracting the certificates (creating the file)
Bonus: Getting the Zscaler IP
Tested on Ubuntu 20 and 18 behind Zscaler proxy.
Without certificate
With certificate
References:
How to install certificates for command line
unable to connect to server: x509: certificate signed by unknown authority
The answer is to "add that proxy's certificate to the CA bundle", thanks to Daniel Stenberg's answer. Then I guess I am suppose to fill in the rest. So here it is my attempt solving the remaining of the problems/questions --
Q: What is the easiest way to get that Zscaler certificate?
A: From here:
Go to Policy > SSL Inspection. In the Intermediate Root Certificate Authority for SSL Interception section, click Download Zscaler Root Certificate. Navigate to the ZscalerRootCerts. zip file and unzip it.
Q: How to add that certificate to the CA bundle?
A: See How to install company proxy certificate:
You can use curl --cacert <CA certificate> to supply your company CA cert.
Or you can add your company CA cert to /etc/pki/tls/certs/ and run make there to make it available system-wide.
This error (SSL certificate problem) means that the CA store that curl uses to verify the server's peer did not contain the cert and therefore the server couldn't be verified.
If want curl to work with a transparent proxy that terminates TLS you must add that proxy's certificate to the CA bundle or completely ignore the certificate check (which I recommend against).
A transparent proxy for TLS will of course make the connection completely unreliable and have broken security properties.
I have a Gitlab installation on a Kimsufi server installed from sources.
I use Apache and HTTPS with self-signed certificate.
Almost everything is working fine.
This is the problem :
I can't clone repository via HTTPS. Only SSH works fine.
fatal: unable to access 'https://xxx/xxx/xxx.git/': The requested URL
returned error: 503
I think the problem comes from the Apache configuration (vhost).
Is there a log file somewhere or specific command I can run to debug this form client side or server side ?
Thx for help
Edit :
The request result with curl :
xxx#xxx:~/temp$ curl -v https://xxx.xxx.fr/xxx/xxx.git
* Hostname was NOT found in DNS cache
* Trying xxx.xxx.xxx.xxx...
* Connected to xx.xx.xx (xx.xx.xx.xx) port 443 (#0)
* 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 alert, Server hello (2):
* SSL certificate problem: self signed certificate
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate
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).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option
I think I have a certificate issue... Or CA ?
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!