OpenSSL version >= 1.1.1 or another SSL library required

[TryThisOneMyFriend]

Hi everyone,

I'm trying to follow the steps as precisily as possibly. But i stumble in this error:

#cmake -DOPENSSL_ROOT_DIR=/opt/boringssl -DOPENSSL_INCLUDE_DIR=/opt/boringssl/include -DOPENSSL_LIBRARIES=/opt/boringssl/lib -Dquiche_ROOT=/opt/quiche -DENABLE_QUICHE=TRUE -DCMAKE_INSTALL_PREFIX=/opt/ats -B build -G Ninja
CMake Error at CMakeLists.txt:279 (message):
  OpenSSL version >= 1.1.1 or another SSL library required


-- Configuring incomplete, errors occurred!
See also "/opt/trafficserver/build/CMakeFiles/CMakeOutput.log".
See also "/opt/trafficserver/build/CMakeFiles/CMakeError.log".

I'm sure to have moved the h3-tools-boringssl/borinssl to the /opt/boringssl after build to make sure it is there. Nonetheless, I keep getting this error.

Any insights?

[brbzull0]

Hi.

CMake is not detecting it's boringssl at all.

Please make sure you have it in the /opt/boringssl folder ( you can paste the folders's content here so we can help)

I'd check the cmake *.log for more details.

[TryThisOneMyFriend]

Hi.

CMake is not detecting it's boringssl at all.

Please make sure you have it in the /opt/boringssl folder ( you can paste the folders's content here so we can help)

I'd check the cmake *.log for more details.

As stated before, I'm sure to have installed the openssl in my distro, plus I inserted the boringssl in the /opt/boringssl path. I'm certain to have followed the right steps. Nonetheless it can't find the boringssl. Can you try it in a new Debian 12 container to see if the error reproduce?

EDIT: I have forgot to mention, I'm trying to follow this tutotial: Building the HTTP/3 tools and libraries form scratch

[TryThisOneMyFriend]

Just complementing:

/opt$ ls -l
total 29
drwxr-xr-x  2 root root  2 Feb  3 12:14 ats
drwxr-xr-x  5 root root  5 Feb 10 16:00 boringssl
...

and contents of borings ssl:

ls /opt/boringssl -l
total 13
drwxr-xr-x 2 root root 3 Feb 10 16:00 bin
drwxr-xr-x 3 root root 3 Feb 10 16:00 include
drwxr-xr-x 3 root root 7 Feb 10 16:00 lib

[bneradt]

A few thoughts:

We maintain Docker CI images with both of these installed in them: ci.trafficserver.apache.org/ats/fedora:41 . I'm not sure whether that fits your workflow, but that may be helpful.

For cmake arguments, here are the Preset values for the boringssl build our Rocky CI uses (you can ignore the opentelemetry_ROOT part): https://github.com/apache/trafficserver/blob/54b42b11a54d80a98190584a3e3518625d7a0f38/CMakePresets.json#L150-L154

That assumes boringssl was installed like so:

BASE=/opt/h3-tools-boringssl tools/build_boringssl_h3_tools.sh

[TryThisOneMyFriend]

A few thoughts:

We maintain Docker CI images with both of these installed in them: ci.trafficserver.apache.org/ats/fedora:41 . I'm not sure whether that fits your workflow, but that may be helpful.

For cmake arguments, here are the Preset values for the boringssl build our Rocky CI uses (you can ignore the opentelemetry_ROOT part):

trafficserver/CMakePresets.json

Lines 150 to 154 in 54b42b1 "OPENSSL_ROOT_DIR": "/opt/h3-tools-boringssl/boringssl", "quiche_ROOT": "/opt/h3-tools-boringssl/quiche", "CMAKE_INSTALL_PREFIX": "/tmp/ats-quiche", "opentelemetry_ROOT": "/opt", "ENABLE_QUICHE": "ON"

That assumes boringssl was installed like so:

BASE=/opt/h3-tools-boringssl tools/build_boringssl_h3_tools.sh

So i tried to change it in the debian ci since i'm using bookworm. I executed it and got the same error. I tried to force it, as described by the tutorial, with the following command:

cmake -DOPENSSL_ROOT_DIR=/opt/h3-tools-boringssl/boringssl -DOPENSSL_INCLUDE_DIR=/opt/h3-tools-boringssl/boringssl/include -Dquiche_ROOT=/opt/h3-tools-boringssl/quiche -DENABLE_QUICHE=TRUE -DCMAKE_INSTALL_PREFIX=/opt/ats -B build -G Ninja

Neither worked.

Anyway, I'm rethinking installing it anyway. Apparently the quic protocol available to us in test is just not as good as the http2. so I will be putting this installation on halt in my system for now.

I won't be closing this topic though in case there is anyone with the same problem wich wants to add something up.

Thanks to everyone for your help.

[itsnikolayy]

So we CAN or CANNOT use BoringSSL / AWS-LC? It seems like we cant use openssl api 1.1.1, which is funny, because HAProxy seems to think its useful https://www.haproxy.com/blog/state-of-ssl-stacks and in the source, it checks for aws-lc / boringssl?

I haven't been able to build trafficserver once since v10. And the fact that no operating system includes ts v10+ should really say something.

In all fairness, Apple, Yahoo, Azion, Akamai, Imperva and Netlify should all be contributing their fair share, so I can't be too upset.

[bneradt]

Thank you for this thread for discussion.

So we CAN or CANNOT use BoringSSL / AWS-LC?

You can use BoringSSL. Our CI jobs verify this. My employer (Yahoo) does not use BoringSSL, but I know that others do. BoringSSL is a bit tricky though in the sense that it is very commit specific. Here's the exact script that the CI images use to install BoringSSL for CI:

https://github.com/apache/trafficserver-ci/blob/main/docker/rockylinux8/build_openssl_h3_tools.sh

Then I suggest following the CMakePresets guidance such as here for how to build it:

https://github.com/apache/trafficserver/blob/a0f4cf537760b0d2b68aa0970db15997cf5b8682/CMakePresets.json#L165-L166

It seems like we cant use openssl api 1.1.1

To be clear, this is incorrect. OpenSSL 1.1.1 and 3.x are both supported by version 10. Although I suspect that most people should be on OpenSSL 3.x at this point. Nevertheless, our ubuntu CI jobs verify OpenSSL 1.1.1 builds.

[bneradt]

I'm going to close this assuming that the above responses are helpful. Please feel free to re-open if there are further issues with builds and openssl/boringssl.