Project

General

Profile

Feature #454

Curl plugin can't fetch certificate revocation list with spaces in url

Added by Andrey T over 6 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Low
Category:
configuration
Target version:
Start date:
21.11.2013
Due date:
Estimated time:
Resolution:
Fixed

Description

If certificate revocation list http uri contains non alfa-numeric symbols,
curl plugin can't fetch it. Web server will response with 400 (bad request)
Non alfa-numeric symbols must be url encoded before pass url to curl_easy_setopt

For example: http://some.host/some list.crl will not be retrived.

Associated revisions

Revision 72a92d4f (diff)
Added by Tobias Brunner over 6 years ago

curl: Replace spaces in URIs with %20

cURL requires the URIs to be URL-encoded. Apparently, some CAs encode CRL
URIs with spaces in them.

Fixes #454.

History

#1 Updated by Tobias Brunner over 6 years ago

  • Category changed from libstrongswan to configuration
  • Status changed from New to Feedback
  • Assignee set to Tobias Brunner

If certificate revocation list http uri contains non alfa-numeric symbols,
curl plugin can't fetch it. Web server will response with 400 (bad request)
Non alfa-numeric symbols must be url encoded before pass url to curl_easy_setopt

While it's true that the documentation says that CURLOPT_URL expects an URL-encoded string, only parts of it can really be URL-encoded. If we simply URL-encoded the complete URI characters such as :, / or ? would be replaced with %3a, %2f and %3F, respectively, which obviously wouldn't work.

While we could add some special treatment just for spaces, I rather think you should encode the URI properly in your certificates, or the crluri option of your ca sections.

RFC 5280 actually says:

..values in the uniformResourceIdentifier field must contain a valid URI as specified in [RFC3986].

And as Appendix A in RFC 3986 shows, spaces are no valid characters in URIs. Therefore, to properly encode CRL URIs in the cRLDistributionPoints extensions of your certificates (or in ipsec.conf) you have to replace those spaces with %20.

#2 Updated by Andrey T over 6 years ago

If we simply URL-encoded the complete URI characters such as :, / or ? would be replaced with %3a, %2f and %3F, respectively, which obviously wouldn't work.

Yes, it is not working. Discovered this when I tried to fix it by myself.)

I rather think you should encode the URI properly in your certificates, or the crluri option of your ca sections.

For me, encode url in the certificates - not an option. CA is not mine.
CA that cause problem, is microsoft certificate authority, it allow
such things, and people use this without thinking.
crluri option also will not work. Because crl itself contains link
to delta crl, which also contains spaces.

#3 Updated by Tobias Brunner over 6 years ago

  • Tracker changed from Issue to Feature
  • Status changed from Feedback to Resolved
  • Target version set to 5.1.2
  • Resolution set to Fixed

I rather think you should encode the URI properly in your certificates, or the crluri option of your ca sections.

For me, encode url in the certificates - not an option. CA is not mine.
CA that cause problem, is microsoft certificate authority, it allow
such things, and people use this without thinking.
crluri option also will not work. Because crl itself contains link
to delta crl, which also contains spaces.

I see. I pushed a couple of patches to the crluri-spaces branch of our Git repository that URL-encode spaces in URIs before sending them to cURL. I also noticed that the libsoup based fetcher can handle spaces in URIs. Thus a workaround for current releases is to use the soup plugin instead of the curl plugin.

#4 Updated by Andrey T over 6 years ago

Thanks for your help, Tobias.

#5 Updated by Tobias Brunner over 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF