10

I am using a company-hosted (Bitbucket) git repository that is accessible via HTTPS. Accessing it (e.g. git fetch) worked using macOS 11 (Big Sur), but broke after an update to macOS 12 Monterey. *

After the update of macOS to 12 Monterey my previous git setup broke. Now I am getting the following error message:

$ git fetch
fatal: unable to access 'https://.../':
error:06FFF089:digital envelope routines:CRYPTO_internal:bad key length

For what it's worth, using curl does not work either:

$ curl --insecure -L -v https://...
*   Trying ...
* Connected to ... (...) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  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, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* error:06FFF089:digital envelope routines:CRYPTO_internal:bad key length
* Closing connection 0
curl: (35) error:06FFF089:digital envelope routines:CRYPTO_internal:bad key length

Accessing the same HTTPS-source via Safari or Firefox works.

As far as I understand, the underlying error "bad key length" error is coming from OpenSSL/LibreSSL, this would be consistent with both git and curl failing after an OS upgrade.

This is the output from openssl:

$ openssl s_client -servername ... -connect ...:443
CONNECTED(00000005)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte TLS RSA CA G1
verify return:1
depth=0 ...
4593010348:error:06FFF089:digital envelope routines:CRYPTO_internal:bad key length:
/System/Volumes/Data/SWE/macOS/BuildRoots/b8ff8433dc/Library/Caches/com.apple.xbs
/Sources/libressl/libressl-75/libressl-2.8/crypto/apple/hmac/hmac.c:188:
---
Certificate chain
 ...
---
No client certificate CA names sent
Server Temp Key: DH, 2048 bits
---
SSL handshake has read 4105 bytes and written 318 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-GCM-SHA384
    Session-ID: 1FA062DC9EEC9A310FF8231F1EB11A3BD6E0778F7AB6E98EAD1020A44CF1A407
    Session-ID-ctx:
    Master-Key:
    Start Time: 1635319904
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

I did try to add the server's certificates into a custom pem file and setting http.sslCAInfo, but that didn't work. As a workaround, I am currently using a proxy that decrypts/re-encrypts HTTPS traffic.

How do I configure git (or all LibreSSL users) to accept the server's certificate?

nd.
  • 8,699
  • 2
  • 32
  • 42
  • I don't have a clue, but despite the error message it appears at least the `openssl s_client -servername ... -connect ...:443` actually successfully completed the TLS handshake. I would attempt this again using a different and recent version of openssl, if only to try to isolate the problem. – President James K. Polk Oct 27 '21 at 13:22
  • @PresidentJamesK.Polk The SSL library being the culprit is consistent with the problem appearing after an OS upgrade. However, this also makes changing the SSL library difficult: as you can see, the library itself is inside of `/Library/Caches`, i.e. the dyld_shared_cache, which makes changes quite tricky – nd. Oct 28 '21 at 20:23
  • 2
    Only LibreSSL (not OpenSSL) uses function FFF=CRYPTO_internal. And although OpenSSL has defined this reason for a long time, AFAICT it was never used until 1.1.1d (after Libre forked) and then only for RC5 (not used in SSL/TLS). Libre does use it including for HMAC as indicated by the error detail from commandline, but path crypto/apple/hmac/ suggests Apple has modified this in a way that may be wrong. It definitely doesn't have anything to do with the server certificate. eBuccaneer's method probably works by using openssl from brew which is not modified by apple. – dave_thompson_085 Nov 02 '21 at 11:30

5 Answers5

15

Setting this ENV var (in e.g. ~/.zshrc) worked for me

export CURL_SSL_BACKEND="secure-transport"
Dali
  • 437
  • 1
  • 6
  • 10
6

Unfortunately I can't provide you with a fix, but I've found a workaround for that exact same problem (company-hosted bitbucket resulting in exact same error). I also don't know exactly why the problem occurs, but my best guess would be that the libressl library shipped with Monterey has some sort of problem with specific (?TLSv1.3) certs. This guess is because the brew-installed openssl v1.1 and v3 don't throw that error when executed with /opt/homebrew/opt/openssl/bin/openssl s_client -connect ...:443

To get around that error, I've built git from source built against different openssl and curl implementations:

  1. install autoconf, openssl and curl with brew (I think you can select the openssl lib you like, i.e. v1.1 or v3, I chose v3)
  2. clone git version you like, i.e. git clone --branch v2.33.1 https://github.com/git/git.git
  3. cd git
  4. make configure (that is why autoconf is needed)
  5. execute LDFLAGS="-L/opt/homebrew/opt/openssl@3/lib -L/opt/homebrew/opt/curl/lib" CPPFLAGS="-I/opt/homebrew/opt/openssl@3/include -I/opt/homebrew/opt/curl/include" ./configure --prefix=$HOME/git (here LDFLAGS and CPPFLAGS include the libs git will be built against, the right flags are emitted by brew on install success of curl and openssl; --prefix is the install directory of git, defaults to /usr/local but can be changed)
  6. make install
  7. ensure to add the install directory's subfolder /bin to the front of your $PATH to "override" the default git shipped by Monterey
  8. restart terminal
  9. check that git version shows the new version

This should help for now, but as I already said, this is only a workaround, hopefully Apple fixes their libressl fork ASAP.

eBuccaneer
  • 118
  • 1
  • 6
  • 1
    I would rather not create a custom git build, but this works, so I accept the solution. However I would really appreciate it if somebody can supply a different solution that does not need this. – nd. Nov 03 '21 at 12:05
  • 2
    For the other users of my company I created a custom homebrew formula that is almost 1:1 the same as the standard `git.gb`; the only differences are the missing bottles and `depends_on "curl"` instead of `uses_from_macos "curl"`. – nd. Nov 03 '21 at 14:20
  • I have same problem. Followed every step from accepted answer but couldn't get it working. Not quite understood the 7th point. Can anyone please explain where to add that /bin? @nd. – BhushanVU Jan 12 '22 at 09:40
  • 1
    @BhushanVU you installed/cloned a version of git, after building there should be a `/bin` folder inside it, let's assume it is `/usr/local/git/out/bin`, then you have to add this folder to the front of your path variable, usually you do this in `~/.zshrc` or `~/.bashrc`, whatever your terminal is. To add it to the front of your path add `GIT=/usr/local/git/out/bin` and `export PATH="$GIT:${PATH}"` to the end of the correct file, each in one line. – eBuccaneer Jan 13 '22 at 10:18
  • I got the `CRYPTO_internal:bad key length` error when connecting to an incoming mail server: `openssl s_client -quiet -crlf -starttls smtp -connect example.com:25`. Using OpenSSL (installed via Homebrew) instead of LibreSSL solves the issue: `/usr/local/opt/openssl/bin/openssl s_client -quiet -crlf -starttls smtp -connect example.com:25`. Assuming the problem is with LibreSSL (rather than the server and OpenSSL), I hope Apple addresses this issue soon. – Kaspar Etter Jan 20 '22 at 07:45
  • 1
    @nd. I think the answer to this problem should be upgrading to macOS 12.3 rather than deploying the "create a custom git build" workaround – Velociround Mar 29 '22 at 17:37
4

Edit: macOS 12.3 was officially released on march 13th, 2022 and the issue reported on this question has been fixed. Personally I have removed the workaround I had deployed and I suggest others do the same to keep up with the new versions.

Previous answer:

Apparently Apple has updated the LibreSSL version on macOS Monterey 12.3 developer beta 2 and later so this issue no longer happens. The stable 12.3 version is yet to be released but I have tested the developer beta and confirmed it fixed the issue for me, so there should soon be no need to deploy the workarounds mentioned on this question.

I guess macOS 12.3 will probably be released some time next month.

Velociround
  • 611
  • 7
  • 18
2

Spent almost 3 weeks to solve this on MACOS 12.1 Monterey. I was getting

fatal: unable to access 'https://.../':
error:06FFF089:digital envelope routines:CRYPTO_internal:bad key length

Here's what worked:

  1. Execute in a terminal with zsh (Z Shell):

    echo 'export CURL_SSL_BACKEND="secure-transport" ' >> ~/.zshenv

  2. Reload Changes. Type below line in terminal

    source ~/.zshenv

  3. Check if your new variable is set properly. Type below line in terminal

    echo CURL_SSL_BACKEND

BhushanVU
  • 3,455
  • 1
  • 24
  • 33
0

Accepted answer worked, but you might have to check if the lib and include paths are correct with

brew info openssl

and

brew info curl
Jonas Wiebe
  • 1
  • 1