Ръководство за конфигуриране на SSL, TLS и прокси в curl

Конфигурирането на HTTPS сертификати, TLS версии, прокси сървъри и персонализирано DNS разрешаване в curl е от съществено значение за сигурна API комуникация, CI/CD пайплайни и отстраняване на мрежови проблеми. Това ръководство покрива всяка опция за SSL, TLS, прокси и мрежа — от деактивиране на проверките на сертификати с -k за локална разработка до настройване на mutual TLS с --cert и маршрутизиране на трафик през SOCKS5 прокси. Всяка опция включва ясно обяснение, съображения за сигурност и готов за копиране пример.

Кратка справка за опциите за SSL и прокси

-kSSL/TLS

Позволяване на несигурни връзки — пропускане на цялата SSL верификация

--cacertSSL/TLS

Верифициране на сървърния сертификат спрямо конкретна CA група

--certSSL/TLS

Предоставяне на клиентски сертификат за mutual TLS удостоверяване

--keySSL/TLS

Предоставяне на файла с частен ключ за клиентския сертификат

--tlsv1.2SSL/TLS

Използване на TLS версия 1.2 или по-висока за връзката

--tlsv1.3SSL/TLS

Използване на TLS версия 1.3 или по-висока за връзката

--ssl-reqdSSL/TLS

Изискване на SSL/TLS за връзката (неуспех ако не е налично)

--ciphersSSL/TLS

Указване кои SSL шифри да се използват за връзката

--cert-typeSSL/TLS

Указване на типа на клиентския сертификат (PEM, DER, ENG, P12)

--pinnedpubkeySSL/TLS

Фиксиране и верифициране на публичния ключ на сървъра (HPKP стил)

-xПрокси

Маршрутизиране на целия трафик през указания прокси сървър

--socks5Прокси

Маршрутизиране на връзката през SOCKS5 прокси

--proxy-userПрокси

Предоставяне на потребител:парола за прокси сървъра

--noproxyПрокси

Списък с хостове, които не трябва да минават през проксито

--socks5-hostnameПрокси

SOCKS5 прокси с DNS разрешаване през проксито

--proxy-cacertПрокси

CA сертификат за верифициране на самото HTTPS прокси

--resolveМрежа

Свързване на конкретна двойка host:port с персонализиран IP адрес

--connect-toМрежа

Свързване към различен host:port от указания в URL адреса

--local-portМрежа

Задаване на номер или диапазон на локален порт за връзката

--interfaceМрежа

Свързване на връзката към конкретен мрежов интерфейс

--dns-serversМрежа

Използване на персонализирани 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/data

curl --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/secure

curl --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/secure

curl --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-reqd

Изискване на SSL/TLS за връзката (неуспех ако не е налично)

--ciphers

Указване кои SSL шифри да се използват за връзката

--cert-type

Указване на типа на клиентския сертификат (PEM, DER, ENG, P12)

--pinnedpubkey

Фиксиране и верифициране на публичния ключ на сървъра (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/data

curl --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/data

curl --proxy-user: Удостоверяване на проксито

Какво прави
Опцията --proxy-user (или -U) изпраща данни за удостоверяване към прокси сървъра. Форматът е user:password. Това е отделно от удостоверяването на сървъра (-u).
Кога да се използва
Необходимо, когато прокси сървърът изисква удостоверяване — често срещано в корпоративни и предприемачески мрежови среди. Данните за достъп се изпращат към проксито, а не към целевия сървър.
$ curl -x http://proxy.corp.com:3128 -U user:pass https://external-api.com/data

curl --noproxy: Заобикаляне на проксито за конкретни хостове

Какво прави
Опцията --noproxy указва разделен със запетаи списък от хостове, домейни или IP адреси, които трябва да заобикалят проксито и да се свързват директно. Поддържа заместващи символи: *.example.com съвпада с всички поддомейни.
Кога да се използва
Използвайте за изключване на localhost, вътрешни услуги или конкретни домейни от проксито. Това е важно, когато проксито е зададено глобално чрез променливи на средата, но някои хостове (като локални услуги) се нуждаят от директен достъп. Използвайте *, за да заобиколите проксито за всички хостове.
$ curl -x http://proxy:8080 --noproxy "localhost,127.0.0.1,*.internal.com" https://localhost:3000/api

Допълнителни прокси опции

--socks5-hostname

SOCKS5 прокси с DNS разрешаване през проксито

--proxy-cacert

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/health

curl --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

Допълнителни мрежови опции

--local-port

Задаване на номер или диапазон на локален порт за връзката

--interface

Свързване на връзката към конкретен мрежов интерфейс

--dns-servers

Използване на персонализирани 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/status

Mutual 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/data

Docker контейнер с вътрешен CA

Когато услуги в Docker използват сертификати от вътрешен CA, монтирайте CA сертификата в контейнера и го посочете с --cacert. Това е по-сигурно от -k, защото все още валидира веригата на сертификатите.

$ curl --cacert /etc/ssl/certs/internal-ca.crt https://service.docker.internal:8443/health

SOCKS5 прокси през 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 пайплайни.