# Persuading file(DOWNLOAD) to do best-effort for ssl revoke

**URL:** <https://discourse.cmake.org/t/persuading-file-download-to-do-best-effort-for-ssl-revoke/13539>\
**Category:** Code\
**Created:** [February 4, 2025, 10:53pm UTC](https://discourse.cmake.org/t/persuading-file-download-to-do-best-effort-for-ssl-revoke/13539 "2025-02-04T22:53:27Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![brewmook](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/c6cbf5/32.png) [@brewmook](https://discourse.cmake.org/u/brewmook)\
**Post date:** [February 4, 2025, 10:53pm UTC](https://discourse.cmake.org/t/persuading-file-download-to-do-best-effort-for-ssl-revoke/13539/1 "2025-02-04T22:53:27Z")

</div>

Hi,

The embedded libcurl seems to ignore my `.curlrc`. I’ve tried try setting `CURLRC` or `CURL_HOME` env vars in an effort to persuade it, but to no avail.

I’m trying to get it to do `ssl-revoke-best-effort` to work around a quirky certificate chain I have no control over. I’d rather not break out the `execute_process()` to work around the lack of “best effort” options to `file(DOWNLOAD)`. This does the job for curl on the command line and for vcpkg binary cache, but not `file(DOWNLOAD)`.

Yes, `TLS_VERIFY` off does the job, but it’s not ideal. Can I be more specific somehow?

P.S. This is Windows, CMake 3.30.5.

Thanks,  
Dave.

---

<div class="post-metadata">

**Author:** ![scivision](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/s/a87d85/32.png) [@scivision](https://discourse.cmake.org/u/scivision)\
**Post date:** [February 5, 2025, 3:45pm UTC](https://discourse.cmake.org/t/persuading-file-download-to-do-best-effort-for-ssl-revoke/13539/2 "2025-02-05T15:45:39Z")

</div>

If an option CURLRC could be added internally to CMake command file(DOWNLOAD) and file(UPLOAD) similar to how the NETRC option is implemented, this would allow users to specify arbitrarily complex per-command configurations.

For example, like your case where you want the command to have TLS verify on, but allow for some systems that have issues with the cert chain.

---

<div class="post-metadata">

**Author:** ![brewmook](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/c6cbf5/32.png) [@brewmook](https://discourse.cmake.org/u/brewmook)\
**Post date:** [February 5, 2025, 4:04pm UTC](https://discourse.cmake.org/t/persuading-file-download-to-do-best-effort-for-ssl-revoke/13539/3 "2025-02-05T16:04:03Z")

</div>

Yes, that would suit me just fine.

I guess I’m asking has it been deliberately hobbled, or am I just not doing it right?

---

<div class="post-metadata">

**Author:** ![scivision](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/s/a87d85/32.png) [@scivision](https://discourse.cmake.org/u/scivision)\
**Post date:** [February 5, 2025, 6:32pm UTC](https://discourse.cmake.org/t/persuading-file-download-to-do-best-effort-for-ssl-revoke/13539/4 "2025-02-05T18:32:26Z")

</div>

I think it was just never implemented. Because until recently CMake TLS defaulted to off, such problems weren’t noticed.
