Invalid URL in CRAN checks

I'm trying to update a package in CRAN and I get these errors:

Found the following (possibly) invalid URLs:
  URL: https://doi.org/10.1175/1520-0469(1985)042<0217:OTTDPO>2.0.CO;2
    From: man/EPflux.Rd
    Status: Error
    Message: libcurl error code 35:
        schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed).

The URLs are valid and are actually created with the \doi{} macro (e.g. \doi{10.1175/1520-0469(1985)042<0217:OTTDPO>2.0.CO;2})

Even using encoded URLs (per stevec's suggestion)fail with the same error:

Found the following (possibly) invalid URLs:
  URL: https://doi.org/10.1175/1520-0469(1985)042%3C0217:OTTDPO%3E2.0.CO;2
    From: man/EPflux.Rd
    Status: Error
    Message: libcurl error code 35:
        schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed).

Any advice on how to solve this?

I think the reason this is happening is because

https://doi.org/10.1175/1520-0469(1985)042<0217:OTTDPO>2.0.CO;2

is redirecting to

https://journals.ametsoc.org/view/journals/atsc/42/3/1520-0469_1985_042_0217_ottdpo_2_0_co_2.xml

Can you try changing the URL to https://journals.ametsoc.org/view/journals/atsc/42/3/1520-0469_1985_042_0217_ottdpo_2_0_co_2.xml and see if that passes the check?

Another possibility

From here):

some (DOIs) require encoding so that the DOI works correctly when used in URL form

So you perhaps you can encode the url first

URLencode("https://doi.org/10.1175/1520-0469(1985)042<0217:OTTDPO>2.0.CO;2")
[1] "https://doi.org/10.1175/1520-0469(1985)042%3C0217:OTTDPO%3E2.0.CO;2"

Also note:

We strongly recommend that only the following characters are used within a DOI name: “0–9”, “a–z”, and “-._/”.

So perhaps the < characters are causing this issue? (possibly ( too)

Another idea

Noting this from the error message:

This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed).

If we try again not worrying about ssl, that may work.

In otherwords, try using this url instead: http://doi.org/10.1175/1520-0469(1985)042<0217:OTTDPO>2.0.CO;2