Can't use ecc key

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?)

  • 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?

problem is with installing the certificate for luci (uhttpd)

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.

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)

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

        Version: 3 (0x2)
        Serial Number:
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
            Not Before: Jan 25 23:48:38 2018 GMT
            Not After : Apr 25 23:48:38 2018 GMT
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                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
            X509v3 Subject Key Identifier:
            X509v3 Authority Key Identifier:

            Authority Information Access:
                OCSP - URI:
                CA Issuers - URI:

            X509v3 Subject Alternative Name:
            X509v3 Certificate Policies:
                  User Notice:
                    Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at

    Signature Algorithm: sha256WithRSAEncryption

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

  • Subject:
    • 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. *

  • OID - Not sure exactly what this is, as the OID Repo only recognizes

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.

certificate is create by

problem could be X509v3 Key Usage: Digital Signature

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

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

    • 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

    • Like DHE_RSA, except CA used a DSA key in lieu of RSA

Elliptic-Curve Key Exchange

    • 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

    • Like ECDH_ECDSA, except CA used an RSA key

    • 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

    • 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.