Can't use ecc key

Ansuel · January 25, 2018, 5:27pm

I tried to use ecc from let's encrypt but i always get error chiper mismatch from chrome or
OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure from curl

I use openssl (should i enable sslv3 support?)

lleachii · January 25, 2018, 6:47pm

Is this regarding installing the certificate on an OpenWRT/LEDE device?
Is this an issue with Curl on OpenWRT/LEDE connecting to an HTTPS server using an ecc cert?

Ansuel · January 25, 2018, 6:59pm

problem is with installing the certificate for luci (uhttpd)

JW0914 · January 26, 2018, 2:07pm

No. SSLvX (1, 2, or 3) are not secure, which is why TLS only should utilized (TLS is the default, unless one explicitly enables SSLvX).

What version of curl and openssl do you have installed?
- curl: opkg list-installed | grep curl
- openssl: opkg list-installed | grep openssl
This appears to be an issue that pops up with curl, and according to numerous posts garnished from google, updating curl and openssl should fix the issue.

On a side note...

I've never been a big fan of Let's Encrypt (great idea, but it creates more problems than it solves) due to a number of issues, from a lack of security (last I checked, they don't adequately maintain CRLs, of which is what one is paying for when one buys a signed certificate from a commercial certificate authority), to certs expiring in a fairly short period. I always recommend for home users to generate their own CA, then use that to sign certs.
- I created a prebuilt openssl.cnf, which contains all information and commands required starting on Line 430, and if you choose to go that route, shoot me a PM and I'll walk you through what needs to be customized.

Ansuel · January 26, 2018, 4:09pm

problem is actually with chrome that doesn't let me open the webui for the chiper error mismatch...
openssl is compiled with all flag in menuconfig (just cause i can ahahah)

i use let's encrypt as i hate the error that cause self signed cert in internet (as i use ddns service)

JW0914 · January 26, 2018, 4:47pm

So how does accessing the WebUI and the curl error message tie together? Accessing the WebUI has zero to do with curl

Please issue the following command openssl x509 -text -noout -in <name_of_webui_cert> and post the output in a code box

Ansuel · January 26, 2018, 4:49pm

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:74:9b:73:37:da:94:1e:db:8e:1f:1d:f3:69:ac:9b:5e:08
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
        Validity
            Not Before: Jan 25 23:48:38 2018 GMT
            Not After : Apr 25 23:48:38 2018 GMT
        Subject: CN=www.ansuel.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    04:1f:fb:16:c4:2c:34:9e:fd:ff:1a:cb:23:d9:28:
                    03:be:74:78:ac:b7:13:a7:6e:e9:01:79:bd:0b:1b:
                    0d:ea:c1:13:13:cc:92:48:f5:40:71:35:90:90:58:
                    e9:13:2b:d1:b1:75:60:36:38:e0:e8:af:82:b8:2d:
                    34:de:ad:a6:40:25:4e:22:6a:3b:79:66:28:6d:70:
                    e3:68:41:94:cb:1c:3e:46:4b:7f:45:5c:a8:0b:5f:
                    a4:b2:30:06:73:24:8e
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                B4:71:C4:1B:1E:CF:1B:8E:02:E4:24:D7:AF:45:93:04:43:F8:72:CA
            X509v3 Authority Key Identifier:
                keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1

            Authority Information Access:
                OCSP - URI:http://ocsp.int-x3.letsencrypt.org
                CA Issuers - URI:http://cert.int-x3.letsencrypt.org/

            X509v3 Subject Alternative Name:
                DNS:ansuel.com, DNS:rm-home.ansuel.com, DNS:ta-home.ansuel.com, DNS:www.ansuel.com
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org
                  User Notice:
                    Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/

    Signature Algorithm: sha256WithRSAEncryption
         19:52:bb:37:a0:a4:99:a9:c5:b8:a6:3b:ee:09:1a:27:f0:95:
         a8:da:a6:81:9d:40:68:67:70:94:41:67:90:38:e0:66:66:a1:
         dc:99:16:72:d3:37:9a:bb:fb:74:7a:2e:eb:f5:e2:13:d1:6c:
         fd:53:c8:12:8a:09:63:66:db:d6:1c:01:4b:13:f2:cf:0d:b0:
         4a:d6:12:02:13:ab:ff:74:6c:85:fe:e1:f5:bf:cc:f5:5b:81:
         1b:24:d1:82:c6:89:75:18:f8:cd:54:4b:ee:c0:6f:0c:74:74:
         7c:8f:f1:d1:03:8c:ce:e4:35:7c:97:3f:23:94:58:41:7c:df:
         a2:d6:b6:96:d7:4b:24:f5:5d:d6:4b:7b:b9:ea:11:e0:a9:36:
         c4:65:92:b5:aa:19:4d:e6:29:df:bf:26:80:23:74:84:c3:20:
         b2:9b:81:57:d6:a1:27:e7:0b:00:ca:22:69:ca:36:14:3b:55:
         0b:33:68:3d:8a:d6:6f:68:56:99:a4:c0:51:8e:c6:54:ad:fd:
         4c:f7:64:11:61:0e:82:f9:f6:70:ae:03:70:7d:04:e8:44:a7:
         ff:46:35:6b:d5:8a:8a:f0:73:c0:d8:da:d3:3a:5c:c1:9f:cc:
         62:02:d3:33:ae:02:90:fe:27:d2:76:b1:d4:48:a3:27:2f:29:
         06:ab:4d:7a

now on the webui i have the normal cert... if you want i can place the ecc one so you can make some test

(the host is actually rm-home.ansuel.com)

JW0914 · January 26, 2018, 5:30pm

Subject: CN=www.ansuel.com
- The CN should not contain an IP or DNS, as this was obsoleted decades ago in the RFC, which is why Google chose to no longer support an IP or DNS in the CN, as it's insecure to do so. This is what the SAN profile is for.
X509v3 Key Usage: Digital Signature
- See the Key Exchange & EC Key Exchange tabs to show what's required for ECDH & ECDHE exchanges to double check everything is as it should be for ECDSA, as I've never utilized DSA before.
X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication
- I don't know of any server daemon that can act as a client and server at the same time, off the same config. Unless this is possible, a certificate should have one or the other EKUs serverAuth or clientAuth, not both.
X509v3 Subject Alternative Name:
- You may already know this, but I believe SANs support wildcard addresses (i.e. *.ansuel.com)
OID 1.3.6.1.4.1.44947.1.1.1 - Not sure exactly what this is, as the OID Repo only recognizes 1.3.6.1.4.1.44947

When you navigate to your WebUI in chrome, what is the exact chrome error being shown? Open the dev tools (CTRL + SHIFT + J) - Security tab

The CIPHER_MISMATCH error normally occurs when the browser has dropped support for a specific cipher suite due to security reasons. Please also list the Cipher being utilized on the Security page.

Ansuel · January 26, 2018, 5:38pm

certificate is create by acme.sh

problem could be X509v3 Key Usage: Digital Signature

and let's encrypt doesn't support wildcard (will be fully available on February 27, 2018.)

JW0914 · January 26, 2018, 5:41pm

Digital Signature is required for DHE_DSA exchange.

I personally recommend including the following in all server certs:
- X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment, Key Agreement
- keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment, keyAgreement

Key Exchange

DH_RSA
- Key exchange occurs via a static Diffie-Hellman key
  - Server public key must be a Diffie-Hellman key
  - Diffie-Hellman key must have been issued by a CA
  - CA must be using an RSA key signing key
DH_DSA
- Like DH_RSA, except CA used a DSA key in lieu of RSA
DHE_RSA
- Key exchange occurs via an ephemeral Diffie-Hellman
  - Server dynamically generates & signs a DH public key, sending it to the client
  - Server Public Key must be an RSA key
  - Server certificate must utilize KU digitalSignature
DHE_DSA
- Like DHE_RSA, except CA used a DSA key in lieu of RSA

Elliptic-Curve Key Exchange

ECDH_ECDSA
- Like DH_DSA, but with elliptic curves
  - Server public key must be an ECDH key
  - Server certificate must be issued by a CA utilizing an ECDSA public key
ECDH_RSA
- Like ECDH_ECDSA, except CA used an RSA key
ECDHE_ECDSA
- Server sends dynamically generated EC Diffie-Hellman key, signing it via it's ECDSA key
  - Equivalent to DHE_DSS, but with elliptic curves for both the Diffie-Hellman & signature
ECDHE_RSA
- Like ECDHE_ECDSA, except Server public key is an RSA key
  - Server public key signs the ephemeral EC Diffie-Hellman key

This won't occur if the CA/ICA is installed on the device (the only reason why one doesn't get untrusted errors for commercially signed certs are those CAs are apart of the default OS install). See the Linux/BSD and Windows tabs.