Ръководство за конфигуриране на SSL, TLS и прокси в curl
Конфигурирането на HTTPS сертификати, TLS версии, прокси сървъри и персонализирано DNS разрешаване в curl е от съществено значение за сигурна API комуникация, CI/CD пайплайни и отстраняване на мрежови проблеми. Това ръководство покрива всяка опция за SSL, TLS, прокси и мрежа — от деактивиране на проверките на сертификати с -k за локална разработка до настройване на mutual TLS с --cert и маршрутизиране на трафик през SOCKS5 прокси. Всяка опция включва ясно обяснение, съображения за сигурност и готов за копиране пример.
Кратка справка за опциите за SSL и прокси
Позволяване на несигурни връзки — пропускане на цялата SSL верификация
Верифициране на сървърния сертификат спрямо конкретна CA група
Предоставяне на клиентски сертификат за mutual TLS удостоверяване
Предоставяне на файла с частен ключ за клиентския сертификат
Използване на TLS версия 1.2 или по-висока за връзката
Използване на TLS версия 1.3 или по-висока за връзката
Изискване на SSL/TLS за връзката (неуспех ако не е налично)
Указване кои SSL шифри да се използват за връзката
Указване на типа на клиентския сертификат (PEM, DER, ENG, P12)
Фиксиране и верифициране на публичния ключ на сървъра (HPKP стил)
Маршрутизиране на целия трафик през указания прокси сървър
Маршрутизиране на връзката през SOCKS5 прокси
Предоставяне на потребител:парола за прокси сървъра
Списък с хостове, които не трябва да минават през проксито
SOCKS5 прокси с DNS разрешаване през проксито
CA сертификат за верифициране на самото HTTPS прокси
Свързване на конкретна двойка host:port с персонализиран IP адрес
Свързване към различен host:port от указания в URL адреса
Задаване на номер или диапазон на локален порт за връзката
Свързване на връзката към конкретен мрежов интерфейс
Използване на персонализирани DNS сървъри вместо системните по подразбиране (c-ares)
curl -k: Игнориране на грешки в SSL сертификати
- Какво прави
- Опцията
-k(или--insecure) деактивира цялата SSL/TLS верификация на сертификати. curl няма да проверява дали сървърният сертификат е подписан от доверен CA, дали името на хоста съвпада или дали сертификатът е изтекъл. - Кога да се използва
- Използвайте само за локална разработка със самоподписани сертификати или тестови среди. За staging/production използвайте
--cacertс реалния CA сертификат — това е по-сигурно и по-изрично.
$ curl -k https://localhost:8443/api/healthНикога не използвайте -k в продуктови скриптове или CI/CD пайплайни. Това деактивира цялата валидация на сертификати, правейки вашата връзка уязвима за атаки от тип "човек по средата". Използвайте --cacert, за да се доверите на конкретен CA.
curl --cacert: Използване на персонализиран CA сертификат
- Какво прави
- Опцията
--cacertказва на curl да верифицира SSL сертификата на сървъра спрямо конкретен CA (Certificate Authority) файл с група сертификати в PEM формат, вместо хранилището за доверие по подразбиране на системата. - Кога да се използва
- Използвайте, когато вашият сървър използва сертификат, подписан от частен или вътрешен CA, който не е в системното хранилище за доверие. Това е често срещано в корпоративни среди, Kubernetes клъстери и Docker конфигурации с вътрешна PKI.
$ curl --cacert /path/to/corporate-ca.pem https://internal-api.example.com/datacurl --cert: Клиентски сертификат (Mutual TLS)
- Какво прави
- Опцията
--certпредоставя клиентски сертификат за mutual TLS (mTLS). При mTLS и сървърът, и клиентът представят сертификати, за да верифицират идентичността си взаимно. Файлът на сертификата трябва да бъде в PEM или PKCS#12 формат. - Кога да се използва
- Необходимо, когато сървърът изисква удостоверяване с клиентски сертификат — често срещано в банкови API-та, правителствени услуги, IoT комуникация и архитектури с нулево доверие. Винаги го свързвайте с
--key, освен ако ключът е вграден в cert файла.
$ curl --cert client.pem --key client-key.pem https://mtls-api.example.com/securecurl --key: Частен ключ на клиентския сертификат
- Какво прави
- Опцията
--keyуказва файла с частен ключ, който е свързан с клиентския сертификат, предоставен чрез--cert. Ключът трябва да съответства на сертификата. Ако ключът е защитен с парола, curl ще поиска паролата (или използвайте--pass). - Кога да се използва
- Винаги използвайте заедно с
--cert. Ако частният ключ вече е вграден в cert файла (типично за PKCS#12 / .p12 файлове), можете да пропуснете--key.
$ curl --cert client.pem --key client-key.pem --cacert server-ca.pem https://api.example.com/securecurl --tlsv1.2: Принудително TLS 1.2 минимум
- Какво прави
- Опцията
--tlsv1.2принуждава curl да използва TLS 1.2 като минимална приемлива версия за SSL/TLS ръкостискане. По-старите протоколи (TLS 1.0, 1.1, SSLv3) се отхвърлят. - Кога да се използва
- Използвайте за налагане на минимален стандарт за сигурност. TLS 1.2 е задължителен за PCI-DSS съответствие и се поддържа от всички модерни сървъри. Повечето съвременни curl компилации използват TLS 1.2+ по подразбиране, но тази опция го прави изрично.
$ curl --tlsv1.2 -v https://secure.example.com/api 2>&1 | grep 'SSL connection'curl --tlsv1.3: Принудително TLS 1.3 минимум
- Какво прави
- Опцията
--tlsv1.3принуждава curl да използва TLS 1.3 — най-бързата и най-сигурната TLS версия. TLS 1.3 елиминира допълнителното пътуване при ръкостискането (поддръжка на 0-RTT) и премахва всички остарели набори шифри. - Кога да се използва
- Използвайте, когато знаете, че сървърът поддържа TLS 1.3 и искате най-добрата производителност и сигурност. Забележка: TLS 1.3 изисква OpenSSL 1.1.1+ или съвместима TLS библиотека. Не всички сървъри го поддържат все още.
$ curl --tlsv1.3 https://modern-api.example.com/dataДопълнителни SSL/TLS опции
Изискване на SSL/TLS за връзката (неуспех ако не е налично)
Указване кои SSL шифри да се използват за връзката
Указване на типа на клиентския сертификат (PEM, DER, ENG, P12)
Фиксиране и верифициране на публичния ключ на сървъра (HPKP стил)
curl -x: Използване на HTTP/HTTPS прокси
- Какво прави
- Опцията
-x(или--proxy) маршрутизира целия curl трафик през указания прокси сървър. Форматът е[protocol://]host[:port]. Поддържани прокси протоколи: HTTP, HTTPS, SOCKS4, SOCKS5. - Кога да се използва
- Използвайте за корпоративни прокси сървъри, отстраняване на грешки с инструменти като Fiddler, Charles или mitmproxy, тестване на географски ограничения или когато нямате пряк достъп до интернет. Можете също да зададете променливите на средата
http_proxy/https_proxy.
$ curl -x http://proxy.example.com:8080 https://api.example.com/datacurl --socks5: Използване на SOCKS5 прокси
- Какво прави
- Опцията
--socks5казва на curl да използва SOCKS5 прокси за TCP връзката. За разлика от HTTP проксита, SOCKS5 работи на TCP ниво и може да обработва всеки протокол — не само HTTP. DNS разрешаването се извършва локално по подразбиране; използвайте--socks5-hostname, за да разрешавате DNS през проксито. - Кога да се използва
- Използвайте за SSH тунели (
ssh -D), достъп до мрежата Tor или когато проксито трябва да обработва протоколи, различни от HTTP. SOCKS5 поддържа UDP и може по желание да обработва DNS — правейки го по-гъвкав от HTTP проксита.
$ curl --socks5 localhost:1080 https://api.example.com/datacurl --proxy-user: Удостоверяване на проксито
- Какво прави
- Опцията
--proxy-user(или-U) изпраща данни за удостоверяване към прокси сървъра. Форматът еuser:password. Това е отделно от удостоверяването на сървъра (-u). - Кога да се използва
- Необходимо, когато прокси сървърът изисква удостоверяване — често срещано в корпоративни и предприемачески мрежови среди. Данните за достъп се изпращат към проксито, а не към целевия сървър.
$ curl -x http://proxy.corp.com:3128 -U user:pass https://external-api.com/datacurl --noproxy: Заобикаляне на проксито за конкретни хостове
- Какво прави
- Опцията
--noproxyуказва разделен със запетаи списък от хостове, домейни или IP адреси, които трябва да заобикалят проксито и да се свързват директно. Поддържа заместващи символи:*.example.comсъвпада с всички поддомейни. - Кога да се използва
- Използвайте за изключване на localhost, вътрешни услуги или конкретни домейни от проксито. Това е важно, когато проксито е зададено глобално чрез променливи на средата, но някои хостове (като локални услуги) се нуждаят от директен достъп. Използвайте
*, за да заобиколите проксито за всички хостове.
$ curl -x http://proxy:8080 --noproxy "localhost,127.0.0.1,*.internal.com" https://localhost:3000/apiДопълнителни прокси опции
SOCKS5 прокси с DNS разрешаване през проксито
CA сертификат за верифициране на самото HTTPS прокси
curl --resolve: Персонализирано DNS разрешаване
- Какво прави
- Опцията
--resolveпредоставя персонализиран IP адрес за конкретна двойкаhost:port, напълно заобикаляйки DNS търсенето. Форматът еhost:port:address. Могат да се предоставят множество--resolveзаписи. - Кога да се използва
- Съществено за тестване преди DNS разпространение, верифициране на конкретен бекенд зад балансьор на натоварването или локална разработка, където е нужно реално име на хост за валидация на SSL сертификат. За разлика от редактирането на
/etc/hosts, това е за конкретна заявка и порт.
$ curl --resolve api.example.com:443:127.0.0.1 https://api.example.com/healthcurl --connect-to: Пренасочване на връзката към различен хост
- Какво прави
- Опцията
--connect-toпренасочва TCP връзката към различна двойкаhost:port, като запазва оригиналния URL адрес за HTTP заявката (включително хедъраHostи SNI). Формат:HOST1:PORT1:HOST2:PORT2. - Кога да се използва
- Използвайте за тестване на конкретен бекенд сървър зад балансьор на натоварването без промяна на DNS или
/etc/hosts. За разлика от--resolve, това свързва host:port с host:port (не с IP), което е полезно, когато целта също има име на хост.
$ curl --connect-to api.example.com:443:backend1.internal:8443 https://api.example.com/healthДопълнителни мрежови опции
Задаване на номер или диапазон на локален порт за връзката
Свързване на връзката към конкретен мрежов интерфейс
Използване на персонализирани DNS сървъри вместо системните по подразбиране (c-ares)
Реални сценарии за SSL и прокси
Тези примери комбинират множество опции за обработка на типични задачи за сигурност и мрежи в разработка, CI/CD и продуктови среди.
Тестване на HTTPS на Localhost
При локална разработка със самоподписан сертификат комбинирайте --resolve с --cacert (или -k за бързо тестване). Това ви позволява да използвате реално име на хост за правилен SSL/SNI без промяна на hosts файла.
$ curl --resolve myapp.local:443:127.0.0.1 --cacert local-ca.pem https://myapp.local/api/statusMutual TLS (удостоверяване с клиентски сертификат)
Някои API-та изискват и сървърът, и клиентът да представят сертификати. Предоставете --cert, --key и --cacert, за да установите напълно верифицирана двупосочна TLS връзка.
$ curl --cert client.pem --key client-key.pem --cacert server-ca.pem https://mtls-api.example.com/dataКорпоративно прокси с удостоверяване
В корпоративни мрежи със задължителни прокси сървъри комбинирайте -x с -U за данни за достъп до проксито. Добавете --noproxy, за да изключите вътрешните услуги от проксито.
$ curl -x http://proxy.corp.com:3128 -U user:pass --noproxy "*.internal.corp" https://external-api.com/dataDocker контейнер с вътрешен CA
Когато услуги в Docker използват сертификати от вътрешен CA, монтирайте CA сертификата в контейнера и го посочете с --cacert. Това е по-сигурно от -k, защото все още валидира веригата на сертификатите.
$ curl --cacert /etc/ssl/certs/internal-ca.crt https://service.docker.internal:8443/healthSOCKS5 прокси през SSH тунел
Създайте SOCKS5 прокси с ssh -D и насочете curl трафика през него с --socks5. Това е полезно за достъп до вътрешни услуги през bastion хост.
$ curl --socks5 localhost:1080 https://internal-api.example.com/statusЧесто задавани въпроси за SSL и прокси в curl
Как да пропусна верификацията на SSL сертификат в curl?
Използвайте curl -k URL или curl --insecure URL. Това деактивира всички проверки на сертификати — изтичане, несъвпадение на име на хост, недоверен CA. Използвайте само за локална разработка. За production използвайте --cacert с реалния CA сертификат.
Как да направя curl да се довери на самоподписан сертификат?
Използвайте curl --cacert /path/to/ca.pem URL, за да укажете CA сертификата, подписал вашия самоподписан сертификат. Това е по-сигурно от -k, защото все още валидира веригата на сертификатите — като се доверява само на вашия конкретен CA.
Как да проверя коя TLS версия използва curl?
Изпълнете curl -v URL и потърсете реда * SSL connection using TLSv1.x / CipherSuite в подробния изход. За принудително задаване на конкретна версия използвайте --tlsv1.2 или --tlsv1.3.
Какво е mutual TLS (mTLS) и как да го използвам с curl?
Mutual TLS изисква и сървърът, и клиентът да представят сертификати. Използвайте: curl --cert client.pem --key client-key.pem --cacert server-ca.pem URL. Двойката --cert/--key удостоверява клиента; --cacert верифицира сървъра.
Как да използвам curl през HTTP прокси?
Използвайте curl -x http://proxy:port URL. За HTTPS прокси: curl -x https://proxy:port URL. Алтернативно задайте променливите на средата http_proxy и https_proxy — curl ги улавя автоматично.
Как да използвам curl със SOCKS5 прокси?
Използвайте curl --socks5 host:port URL за локално DNS разрешаване или curl --socks5-hostname host:port URL за DNS разрешаване през проксито (важно за поверителност/Tor). Пример със SSH тунел: ssh -D 1080 user@bastion, след това curl --socks5 localhost:1080 URL.
Как да се удостоверя с прокси сървър в curl?
Използвайте curl -x http://proxy:port -U user:password URL. Опцията -U (или --proxy-user) изпраща данни за достъп до проксито. Това е отделно от -u, което удостоверява с целевия сървър.
Как да изключа определени хостове от проксито в curl?
Използвайте --noproxy "localhost,127.0.0.1,*.internal.com" или задайте променливата на средата NO_PROXY. Поддържа заместващи символи (*.example.com). Използвайте --noproxy "*", за да заобиколите проксито изцяло за единична заявка.
Как да тествам HTTPS на localhost с curl?
За бързо тестване: curl -k https://localhost:8443/. За правилна валидация: curl --resolve myapp.local:443:127.0.0.1 --cacert local-ca.pem https://myapp.local/. Подходът с --resolve позволява правилно съвпадение на името на хоста на сертификата.
Как да заменя DNS разрешаването за конкретен хост в curl?
Използвайте curl --resolve host:port:IP URL. Пример: curl --resolve api.example.com:443:192.168.1.100 https://api.example.com/. Това заобикаля DNS само за тази двойка host:port — без нужда от редактиране на /etc/hosts.
Как да оправя грешката 'SSL certificate problem: certificate has expired' в curl?
Сървърният сертификат е изтекъл. Решения: (1) Подновете сертификата на сървъра, (2) Актуализирайте CA пакета: curl --cacert /path/to/updated-ca.pem URL, (3) Само за тестване: curl -k URL. Проверка на изтичане: curl -v URL 2>&1 | grep expire.
Безопасно ли е да се използва curl --insecure (-k) в production?
Не. Опцията -k деактивира цялата валидация на сертификати — изтичане, име на хост и верига на доверие. Това прави вашата връзка уязвима за атаки от тип "човек по средата". Винаги използвайте --cacert с конкретния CA сертификат в production и CI/CD пайплайни.