Это вопрос о том, как заставить github webhook работать через https. Это также вопрос неопытного человека о лучших методах устранения неполадок.
У меня есть веб-перехватчик github для моего промежуточного сайта, который указывает на https://staging.domain.com/git_webhook
Он отлично работает, если я указываю на http, а не https. Но с https github отвечает: We couldn’t deliver this payload: Service Timeout. Это происходит, даже когда проверка SSL отключена для веб-перехватчика.
Используя Postman и curl, веб-перехватчик отлично работает через https.
То, что я пробовал
- Проверьте, отвечает ли брандмауэр.
Сервер - Ubuntu 18.04 с apparmor, ufw и fail2ban. В ufw https открыт для всех. Я отключил все службы и перезапустил apache, но безуспешно. Я не нашел никаких правил, выделяющих IP-адреса github. Но я неопытен и, возможно, не понимаю, как их искать, если они существуют. Я подумал, что простого кратковременного отключения сервисов будет достаточно, чтобы проверить, задействованы ли они.
Используйте tshark для проверки входящего запроса HTTPS POST от github.
tshark показал, что после «Server Hello, Certificate, Server Key Exchange, Server Hello Done» нет подтверждения. Было 4 или 5 повторных передач [P SH, ACK] с моего сервера на github без ответа от github, затем github закрывает соединение.
Это проблема с моим сертификатом SSL?
Мой основной домен domain.com имеет сертификат Comodo SSL, который не применяется ни к одному субдомену. у моего staging.domain.com есть действующий сертификат SSL Let's Encrypt.
Когда я запускаю openssl s_client -showcerts -servername staging.domain.com -connect staging.domain.com:443 </dev/null, я получаю сертификат Let's Encrypt, принадлежащий staging.domain.com
Но когда я запустите openssl s_client -showcerts -connect staging.domain.com:443 </dev/null Я получаю сертификат Comodo, принадлежащий основному домену. com
Возможно, служба github webhook не может обрабатывать SNI? (И основной, и субдомен Apache virtualhosts включают <ServerName ... >)
Затем я отключил сертификаты Comodo SSL и расширил сертификат Let's Encrypt, включив в него как domain.com, так и staging.domain.com, и перезапустил Apache. По-прежнему "Service Timeout" из github.
Не нравится ли github Let's Encrypt? Я заказал в Comodo бесплатный 30-дневный сертификат и применил его к staging.domain.com. Не повезло.
Когда я запускаю staging.domain.com через https://www.ssllabs.com/ssltest, он показывает сертификат Let's Encrypt, но, что интересно, под ним отображается «Сертификат №2», который является сертификатом Comodo для domain.com. И поскольку доменные имена не совпадают, этот сертификат помечен множеством красных предупреждений. Является ли это ненормальным поведением, и должен ли я найти способ необнаружить сертификат domain.com при посещении (или анализе) staging.domain.com?
На этом этапе у меня все в порядке идей. Буду признателен за любое руководство. Это также мой первый вопрос SO, и я также хочу обратить внимание на свой этикет вопросов.
Редактировать 1: при активации события webhook pu sh, вот результат sudo tshark -d tcp.port==443,ssl -f "net 140.82.112.0/20 or net 185.199.108.0/22 or net 192.30.252.0/22" (это IP-адреса веб-перехватчиков github):
1 0.000000000 140.82.115.240 → <IP OF MY SERVER> TCP 74 64733 → 443 [SYN] Seq=0 Win=26880 Len=0 MSS=8960 SACK_PERM=1 TSval=2233744096 TSecr=0 WS=1024
2 0.000066037 <IP OF MY SERVER> → 140.82.115.240 TCP 74 443 → 64733 [SYN, ACK] Seq=0 Ack=1 Win=61936 Len=0 MSS=8860 SACK_PERM=1 TSval=2212655787 TSecr=2233744096 WS=128
3 0.000879665 140.82.115.240 → <IP OF MY SERVER> TCP 66 64733 → 443 [ACK] Seq=1 Ack=1 Win=27648 Len=0 TSval=2233744097 TSecr=2212655787
4 0.012202817 140.82.115.240 → <IP OF MY SERVER> TLSv1 313 Client Hello
5 0.012281121 <IP OF MY SERVER> → 140.82.115.240 TCP 66 443 → 64733 [ACK] Seq=1 Ack=248 Win=61696 Len=0 TSval=2212655799 TSecr=2233744109
6 0.013146175 <IP OF MY SERVER> → 140.82.115.240 TLSv1.2 2799 Server Hello, Certificate, Server Hello Done
7 0.231698984 <IP OF MY SERVER> → 140.82.115.240 TCP 2799 [TCP Retransmission] 443 → 64733 [PSH, ACK] Seq=1 Ack=248 Win=61696 Len=2733 TSval=2212656019 TSecr=2233744109
8 0.451700300 <IP OF MY SERVER> → 140.82.115.240 TCP 2799 [TCP Retransmission] 443 → 64733 [PSH, ACK] Seq=1 Ack=248 Win=61696 Len=2733 TSval=2212656239 TSecr=2233744109
9 0.895731268 <IP OF MY SERVER> → 140.82.115.240 TCP 2799 [TCP Retransmission] 443 → 64733 [PSH, ACK] Seq=1 Ack=248 Win=61696 Len=2733 TSval=2212656683 TSecr=2233744109
10 1.791706743 <IP OF MY SERVER> → 140.82.115.240 TCP 2799 [TCP Retransmission] 443 → 64733 [PSH, ACK] Seq=1 Ack=248 Win=61696 Len=2733 TSval=2212657579 TSecr=2233744109
11 3.551693664 <IP OF MY SERVER> → 140.82.115.240 TCP 2799 [TCP Retransmission] 443 → 64733 [PSH, ACK] Seq=1 Ack=248 Win=61696 Len=2733 TSval=2212659339 TSecr=2233744109
12 4.930201185 140.82.115.240 → <IP OF MY SERVER> TCP 66 64733 → 443 [FIN, ACK] Seq=248 Ack=1 Win=27648 Len=0 TSval=2233749027 TSecr=2212655799
13 4.930468118 <IP OF MY SERVER> → 140.82.115.240 TCP 66 443 → 64733 [FIN, ACK] Seq=2734 Ack=249 Win=61696 Len=0 TSval=2212660718 TSecr=2233749027
14 4.931240019 140.82.115.240 → <IP OF MY SERVER> TCP 54 64733 → 443 [RST] Seq=249 Win=0 Len=0
И когда я смотрю на расшифрованный вывод tshark, кадр 6 кажется начальной передачей с моего сервера на github информации сертификата SSL . Затем кадры с 7 по 11 - это еще 5 повторных передач той же информации, все без ответа. После этого github просто инициирует закрытие соединения без ошибок.
Редактировать 2: с тех пор я пытался развернуть тестовый сервер с Apache по умолчанию и самозаверяющим SSL-сертификатом. Та же проблема. Я также пробовал протестировать веб-перехватчик на моем сайте publi c, который имеет полностью функциональный, подписанный и оплаченный сертификат Comodo. Та же проблема.