/ Register

Join the community today
Register Now

Wordpress wp-cron SSL connect error with Cloudflare SSL ECDSA

Discussion in 'Blogs & CMS usage' started by Peter Downey, Feb 8, 2015.

Tags:
Previous Thread Next Thread
Loading...
  1. Feb 8, 2015 #1
    Peter Downey

    Peter Downey Member

    64
    24
    8
    May 28, 2014
    Ratings:
    +27
    Local Time:
    9:15 AM
    Hey guys. I'm running into a problem with moving a site to a centminmod vps and figured I'd bring up the issue here, incase somebody else has encountered it before or sees something wrong with my config.

    Here is the important info.
    Right now it's just on a test domain, so most stuff is turned off, including plugins. Up to date centminmod .07 install, with php 5.6, maria db 5.5, pagespeed off, any from of caching or memcached off, uses a self signed ssl certificate behind cloudflare full ssl. The site was installed with ssl on initially, and the wordpress database points to https://. Here is the site itself:twp

    Now onto the problem. The site works, spdy works when checked with spdycheck.org using the self signed ssl cert, but results in the below image when cloudflare full ssl is turned on. The site still works fine though.
    SPDYCheck Testing Websites for SPDY Support.jpeg
    Occasionally, I'm getting a wp-cron error related to ssl, this seems to mainly happen when I make a new post to the site.
    twp.jpeg
    Below is my full wp-config and domain.conf files, with private info redacted.
    Code:
    <?php
/**
* The base configurations of the WordPress.
*
* This file has the following configurations: MySQL settings, Table Prefix,
* Secret Keys, and ABSPATH. You can find more information by visiting
* {@link http://codex.wordpress.org/Editing_wp-config.php Editing wp-config.php}
* Codex page. You can get the MySQL settings from your web host.
*
* This file is used by the wp-config.php creation script during the
* installation. You don't have to use the web site, you can just copy this file
* to "wp-config.php" and fill in the values.
*
* @package WordPress
*/

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'redacted');

/** MySQL database username */
define('DB_USER', 'redacted');

/** MySQL database password */
define('DB_PASSWORD', 'redacted');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

/**#@+
* Authentication Unique Keys and Salts.
*
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
*
* @since 2.6.0
*/
define('AUTH_KEY',         'redacted');
define('SECURE_AUTH_KEY',  'redacted);
define('LOGGED_IN_KEY',    'redacted);
define('NONCE_KEY',        'redacted');
define('AUTH_SALT',        'redacted');
define('SECURE_AUTH_SALT', 'redacted');
define('LOGGED_IN_SALT',   'redacted');
define('NONCE_SALT',       'redacted');

/**#@-*/

/**
* WordPress Database Table prefix.
*
* You can have multiple installations in one database if you give each a unique
* prefix. Only numbers, letters, and underscores please!
*/
$table_prefix  = 'redacted';

/**
* For developers: WordPress debugging mode.
*
* Change this to true to enable the display of notices during development.
* It is strongly recommended that plugin and theme developers use WP_DEBUG
* in their development environments.
*/
define('WP_DEBUG', false);

/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');
/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');
    Code:
    server {
  server_name testingwordpress.com www.testingwordpress.com;
  return 301 https://testingwordpress.com/$request_uri;
}
# HTTPS server
server {
listen 443 ssl spdy;
  server_name testingwordpress.com;
ssl on;
ssl_certificate /usr/local/nginx/ssl/twp.crt;
ssl_certificate_key /usr/local/nginx/ssl/twp.key;
ssl_session_cache      shared:SSL:10m;
        ssl_session_timeout  10m;
        ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
        # mozilla recommended
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!CAMELLIA;
        ssl_prefer_server_ciphers   on;
        add_header Alternate-Protocol  443:npn-spdy/3;
        add_header Strict-Transport-Security max-age=31536000;
        #add_header  X-Content-Type-Options "nosniff";
        #add_header X-Frame-Options DENY;
        spdy_headers_comp 5;
        ssl_buffer_size 1400;
        ssl_session_tickets on;
        # enable ocsp stapling
        #resolver 8.8.8.8 8.8.4.4 valid=10m;
        #resolver_timeout 10s;
        #ssl_stapling on;
        #ssl_stapling_verify on;
        #ssl_trusted_certificate /usr/local/nginx/conf/ssl/domain.com/domain.com-trusted.crt;

# ngx_pagespeed & ngx_pagespeed handler
#include /usr/local/nginx/conf/pagespeed.conf;
#include /usr/local/nginx/conf/pagespeedhandler.conf;
#include /usr/local/nginx/conf/pagespeedstatslog.conf;

# Cloudflare
set_real_ip_from 199.27.128.0/21;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/12;
real_ip_header CF-Connecting-IP;

  # limit_conn limit_per_ip 16;
  # ssi  on;

  access_log /home/nginx/domains/testingwordpress.com/log/access.log combined buffer=32k;
  error_log /home/nginx/domains/testingwordpress.com/log/error.log;

  root /home/nginx/domains/testingwordpress.com/public;
#  include /usr/local/nginx/conf/wpsupercache.conf;
# Rewrites for WordPress SEO XML Sitemap
rewrite ^/sitemap_index.xml$ /index.php?sitemap=1 last;
rewrite ^/([^/]+?)-sitemap([0-9]+)?.xml$ /index.php?sitemap=$1&sitemap_n=$2 last;
 
  location / {
    ## supercache Permalinks and nginx permalinks. uncomment one of them
#        try_files /wp-content/cache/supercache/$http_host/$scheme$cache_uri/index.html $uri $uri/ /index.php?$args ;
         try_files $uri $uri/ /index.php?q=$request_uri;
# block common exploits, sql injections etc
#include /usr/local/nginx/conf/block.conf;
  }
  include /usr/local/nginx/conf/wpsecure.conf;
  include /usr/local/nginx/conf/staticfiles.conf;
  include /usr/local/nginx/conf/php.conf;
  include /usr/local/nginx/conf/drop.conf;
  #include /usr/local/nginx/conf/errorpage.conf;
}
    Any ideas what could be causing this issue? It's a test site on a test server, so I'm happy to try out anyone's ideas.
     
  2. Feb 8, 2015 #2
    eva2000

    eva2000 Administrator Staff Member

    54,361
    12,198
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +18,763
    Local Time:
    12:15 AM
    Nginx 1.27.x
    MariaDB 10.x/11.4+
    not sure, but only thing i can think of is Cloudflare free SSL uses ECC 256 bit SSL with ECDSA signature exchange algorithms while your self signed SSL certificate uses RSA 2048bit traditional SSL with ECDHE signature exchange algorithms. See SSL - ECC 256 bit vs RSA 2048 bit SSL | Centmin Mod Community

    It's likely system available curl doesn't support Cloudflare's ECC 256 bit SSL with ECDSA as I noted in first post of that linked thread.

    You can test in via SSH commands for curl
    Code:
    curl -I https://testingwordpress.com/wp-cron.php
    Code:
    curl -1IsS --ciphers ecdhe_ecdsa_aes_128_sha https://testingwordpress.com/wp-cron.php
    Code:
    curl -16IsS https://testingwordpress.com/wp-cron.php -v
     
  3. Feb 8, 2015 #3
    Peter Downey

    Peter Downey Member

    64
    24
    8
    May 28, 2014
    Ratings:
    +27
    Local Time:
    9:15 AM
    this is the results for all 3
    Code:
    [root@twp~]# curl -I https://testingwordpress.com/wp-cron.php
curl: (35) SSL connect error
[root@twp ~]# curl -1IsS --ciphers ecdhe_ecdsa_aes_128_sha https://testingwordpress.com/wp-cron.php
curl: (59) Unknown cipher in list: ecdhe_ecdsa_aes_128_sha
[root@twp ~]# curl -16IsS https://testingwordpress.com/wp-cron.php -v
* About to connect() to testingwordpress.com port 443 (#0)
*   Trying 2400:cb00:2048:1::681c:1411... connected
* Connected to testingwordpress.com (2400:cb00:2048:1::681c:1411) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12286
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error
     
  4. Feb 8, 2015 #4
    eva2000

    eva2000 Administrator Staff Member

    54,361
    12,198
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +18,763
    Local Time:
    12:15 AM
    Nginx 1.27.x
    MariaDB 10.x/11.4+
    yeah as suspected curl version you use doesn't support ECDSA ECC 256 bit SSL

    what are you yum versions for this output
    Code:
    yum list curl curl-devel libcurl libcurl-devel libssh2 -q
    ensure all is updated too
    Code:
    yum clean all
yum -y update
     
  5. Feb 8, 2015 #5
    Peter Downey

    Peter Downey Member

    64
    24
    8
    May 28, 2014
    Ratings:
    +27
    Local Time:
    9:15 AM
    no updates needed in yum after clean and update. below is the response for versions.
    Code:
    Installed Packages
curl.x86_64                                          7.19.7-40.el6_6.4                                  @updates
libcurl.x86_64                                       7.19.7-40.el6_6.4                                  @updates
libcurl-devel.x86_64                                 7.19.7-40.el6_6.4                                  @updates
libssh2.x86_64                                       1.4.2-1.el6_6.1                                    @updates
     
    Last edited: Feb 8, 2015
  6. Feb 8, 2015 #6
    eva2000

    eva2000 Administrator Staff Member

    54,361
    12,198
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +18,763
    Local Time:
    12:15 AM
    Nginx 1.27.x
    MariaDB 10.x/11.4+
    You ran into same problem I did for testing ECC 256 Bit SSL and ECDSA, CentOS 6.x curl 7.19=* bundled with CentOS versions doesn't support ECC 256 bit SSL. Curl versions from 7.36+ and higher enabled ECC SSL support as long as nss supported it and that came in play with nss 3.16 and higher.

    Redhat upstream bug reported at Bug 1058767 – curl does not support ECDSA certificates is listed as ON_QA as at Dec 2014 and Fixed In Version: curl-7.19.7-43.el6. So we're like 3 versions away as CentOS 6.6 build is 7.19.7-40.el6_6.4 (43 vs 40)

    NSS change log
    Code:
    Notable Changes in NSS 3.16
ECC is enabled by default. It is no longer necessary to set the environment variable NSS_ENABLE_ECC=1 when building NSS. To disable ECC, set the environment variable NSS_DISABLE_ECC=1 when building NSS.
    curl change log
    Code:
    Fixed in 7.36.0 - March 26 2014

Bugfixes:
nss: allow to use ECC ciphers if NSS implements them
    CentOS 6 has NSS 3.16.2+ so that is okay but curl 7.19 backported version still doesn't support ECC/ECDSA SSL.

    So solution is to either
    1. Manually upgrade curl from 7.19 to 7.36+ or higher - current latest is curl 7.40. But curl is used system wide so you could end up breaking the system and other apps that rely on system curl if you're not careful. For my sslspdy.com VPS server I took the risk to manually update to curl 7.37 and then curl 7.40 just for testing as my site uses ECC 256 bit/ECDSA SSL Wildcard certificate there. But you'd be on your own for doing that as I no support would be provided by me and no guarantee it won't break anything else on your server that relies on curl.
    2. Or if curl isn't important just ignore it and or use a different method of calling a file that supports ECDSA/ECC (not sure myself).
    3. Or just upgrade to paid Cloudflare SSL which changes you from ECC/ECDSA to wider compatible RSA 2048bit/ECDHE SSL which curl 7.19 supports.
    4. Or use CentOS 7 has curl 7.29 which has some form of support for ECDSA/ECC only if specifically set the cipher so not sure if that would work for your WP install unless you can edit it's curl command to specifiy specifc cipher like --ciphers ecdhe_ecdsa_aes_128_sha
    example on CentOS 7 with curl 7.29

    specific cipher works

    Code:
    curl -1IsS --ciphers ecdhe_ecdsa_aes_128_sha https://sslspdy.com -v
* About to connect() to sslspdy.com port 443 (#0)
*   Trying 192.184.89.66...
* Connected to sslspdy.com (192.184.89.66) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
* Server certificate:
*       subject: CN=*.sslspdy.com,OU=GGSSL Wildcard SSL,OU=Domain Control Validated
*       start date: Oct 24 00:00:00 2014 GMT
*       expire date: Oct 23 23:59:59 2016 GMT
*       common name: *.sslspdy.com
*       issuer: CN=COMODO ECC Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
> HEAD / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: sslspdy.com
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx centminmod
Server: nginx centminmod
< Content-Type: text/html; charset=utf-8
Content-Type: text/html; charset=utf-8
< Connection: keep-alive
Connection: keep-alive
< Vary: Accept-Encoding
Vary: Accept-Encoding
< Strict-Transport-Security: max-age=31536000; includeSubdomains
Strict-Transport-Security: max-age=31536000; includeSubdomains
< Date: Tue, 20 Jan 1970 19:19:30 GMT
Date: Tue, 20 Jan 1970 19:19:30 GMT
< X-Page-Speed: ngx_pagespeed
X-Page-Speed: ngx_pagespeed
< Cache-Control: max-age=0, no-cache
Cache-Control: max-age=0, no-cache

<
* Connection #0 to host sslspdy.com left intact
    without cipher doesn't work

    Code:
    curl -1IsS https://sslspdy.com -v
* About to connect() to sslspdy.com port 443 (#0)
*   Trying 192.184.89.66...
* Connected to sslspdy.com (192.184.89.66) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12286 (SSL_ERROR_NO_CYPHER_OVERLAP)
* Cannot communicate securely with peer: no common encryption algorithm(s).
* Closing connection 0
    Code:
    curl -I https://sslspdy.com -v
* Rebuilt URL to: https://sslspdy.com/
*   Trying 2604:180:1::fd2c:e402...
* Connected to sslspdy.com (2604:180:1::fd2c:e402) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.2, TLS handshake, Client hello (1):
* TLSv1.2, TLS handshake, Server hello (2):
* TLSv1.2, TLS handshake, CERT (11):
* TLSv1.2, TLS handshake, Server key exchange (12):
* TLSv1.2, TLS handshake, Server finished (14):
* TLSv1.2, TLS handshake, Client key exchange (16):
* TLSv1.2, TLS change cipher, Client hello (1):
* TLSv1.2, TLS handshake, Finished (20):
* TLSv1.2, TLS change cipher, Client hello (1):
* TLSv1.2, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* Server certificate:
*        subject: OU=Domain Control Validated; OU=GGSSL Wildcard SSL; CN=*.sslspdy.com
*        start date: 2014-10-24 00:00:00 GMT
*        expire date: 2016-10-23 23:59:59 GMT
*        subjectAltName: sslspdy.com matched
*        issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO ECC Domain Validation Secure Server CA
*        SSL certificate verify ok.
> HEAD / HTTP/1.1
> User-Agent: curl/7.40.0
> Host: sslspdy.com
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx centminmod
Server: nginx centminmod
< Content-Type: text/html; charset=utf-8
Content-Type: text/html; charset=utf-8
< Connection: keep-alive
Connection: keep-alive
< Vary: Accept-Encoding
Vary: Accept-Encoding
< Strict-Transport-Security: max-age=31536000; includeSubdomains
Strict-Transport-Security: max-age=31536000; includeSubdomains
< Date: Tue, 13 Jan 1970 13:17:25 GMT
Date: Tue, 13 Jan 1970 13:17:25 GMT
< X-Page-Speed: ngx_pagespeed
X-Page-Speed: ngx_pagespeed
< Cache-Control: max-age=0, no-cache
Cache-Control: max-age=0, no-cache
<
* Connection #0 to host sslspdy.com left intact
    Code:
    apt-cache policy curl
curl:
  Installed: 7.26.0-1+wheezy12
  Candidate: 7.26.0-1+wheezy12
  Version table:
*** 7.26.0-1+wheezy12 0
        500 http://security.debian.org/ wheezy/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     7.26.0-1+wheezy11 0
        500 http://ftp.us.debian.org/debian/ wheezy/main amd64 Packages
    Code:
    curl -1IsS https://sslspdy.com -v
* About to connect() to sslspdy.com port 443 (#0)
*   Trying 192.184.89.66...
* connected
* Connected to sslspdy.com (192.184.89.66) 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 ECDHE-ECDSA-AES128-SHA
* Server certificate:
*        subject: OU=Domain Control Validated; OU=GGSSL Wildcard SSL; CN=*.sslspdy.com
*        start date: 2014-10-24 00:00:00 GMT
*        expire date: 2016-10-23 23:59:59 GMT
*        subjectAltName: sslspdy.com matched
*        issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO ECC Domain Validation Secure Server CA
*        SSL certificate verify ok.
> HEAD / HTTP/1.1
> User-Agent: curl/7.26.0
> Host: sslspdy.com
> Accept: */*
>
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx centminmod
Server: nginx centminmod
< Content-Type: text/html; charset=utf-8
Content-Type: text/html; charset=utf-8
< Connection: keep-alive
Connection: keep-alive
< Vary: Accept-Encoding
Vary: Accept-Encoding
< Strict-Transport-Security: max-age=31536000; includeSubdomains
Strict-Transport-Security: max-age=31536000; includeSubdomains
< Date: Tue, 20 Jan 1970 19:33:29 GMT
Date: Tue, 20 Jan 1970 19:33:29 GMT
< X-Page-Speed: ngx_pagespeed
X-Page-Speed: ngx_pagespeed
< Cache-Control: max-age=0, no-cache
Cache-Control: max-age=0, no-cache
* no chunk, no close, no size. Assume close to signal end

<
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
     
    Last edited: Feb 8, 2015
  7. Feb 8, 2015 #7
    eva2000

    eva2000 Administrator Staff Member

    54,361
    12,198
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +18,763
    Local Time:
    12:15 AM
    Nginx 1.27.x
    MariaDB 10.x/11.4+
    This will be a problem for any CentOS 6/7 site using Wordpress and PHP curl functions when paired with Cloudflare's free universal SSL which is ECC 256 bit ECDSA SSL only. Only Cloudflare's paid SSL offerings includes wider compatible RSA 2048 bit ECDHE SSL which curl 7.19 support i.e. WordPress › Support » BruteProtect and Cloudflare

    edit: Redhat upstream bug reported at Bug 1058767 – curl does not support ECDSA certificates is listed as ON_QA as at Dec 2014 and Fixed In Version: curl-7.19.7-43.el6. So we're like 3 versions away as CentOS 6.6 build is 7.19.7-40.el6_6.4 (43 vs 40)
     
    Last edited: Feb 8, 2015
  8. Feb 8, 2015 #8
    Peter Downey

    Peter Downey Member

    64
    24
    8
    May 28, 2014
    Ratings:
    +27
    Local Time:
    9:15 AM
    Wow, so this is a pretty complicated problem. Thanks so much for clearing this up. I've been banging my head on it for a little bit.

    Once again, you're the man.
     
  9. Feb 8, 2015 #9
    eva2000

    eva2000 Administrator Staff Member

    54,361
    12,198
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +18,763
    Local Time:
    12:15 AM
    Nginx 1.27.x
    MariaDB 10.x/11.4+
    Yeah complicated and highlights the real fact, Cloudflare Universal SSL isn't totally free - there are costs (non-monetary in nature) :)
     
  10. Aug 18, 2015 #10
    eva2000

    eva2000 Administrator Staff Member

    54,361
    12,198
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +18,763
    Local Time:
    12:15 AM
    Nginx 1.27.x
    MariaDB 10.x/11.4+
  11. Feb 16, 2016 #11
    Oxide

    Oxide Active Member

    534
    29
    28
    Mar 19, 2015
    Ratings:
    +59
    Local Time:
    12:15 AM
    I have exactly same issue, i am running 1.2.3-eva2000.08 @eva2000

    curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
     
  12. Feb 16, 2016 #12
    eva2000

    eva2000 Administrator Staff Member

    54,361
    12,198
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +18,763
    Local Time:
    12:15 AM
    Nginx 1.27.x
    MariaDB 10.x/11.4+
Previous Thread Next Thread
Loading...

.