The library itself has the kind of compatibility hooks, and zealous porters out there that you'll be surprised what works.
You know all those changes that happened between OpenSSL v1.0 and v1.1? Every project had to work hard to accomodate those changes - compiling that code for older versions still has to work, or companies freak out.
Add LibreSSL into the correct side of the header-files' if-statements. Usually its legacy, but we're recently having to consider different versions of LibreSSL.
When a single if-statement begins to span three lines for readability's sake, you know you're shoving LibreSSL into the seam between OpenSSL versions.
Libp11, the backend for Yubikeys was surprisingly simple to get running on a different SSL backend. Three additional if-statements in one header-file, and one extended out. Code compiles, works beautifully, even past LibreSSL's v2.8.3 that I was running at the time.
BoringSSL - while Im less intimately familiar with Google's offering? I thought they were the first to implement TLSv1.3 - years before anyone else was even considering it.
I have no experience porting anything to it. The only folks I know who do? Are Google Engineers, writing proprietary code. The API is explicitly flagged as unstable/quickly changing on their github mirror.
Google, like always, doesnt care about your needs.
BoringSSL implemented TLSv1.3 years before OpenSSL did.
On the flip side, calling C code in rust is pretty easy - you have the entire libc available, and rust-bindgen[1] generate bindings for you, which in my experience works very well. So, you may also consider writing your program in rust… If that's possible.
[0]: https://github.com/eqrion/cbindgen
[1]: https://github.com/rust-lang/rust-bindgen