ssl - Github webhook over https : "Service timeout"

Question

这个问题是关于使 github webhook 在 https 上工作。这也是一个没有经验的人提出的关于故障排除最佳实践的问题。

我有一个指向 https://staging.domain.com/git_webhook 的临时站点的 github webhook

如果我将它指向 http 而不是 https，它会完美运行。但是使用 https，github 会响应:We couldn’t deliver this payload: Service Timeout .即使为 webhook 禁用 SSL 验证也会发生这种情况。

使用 Postman 和 curl，webhook 可以在 https 上完美运行。

我试过的

检查防火墙是否负责。

服务器是带有 apparmor、ufw 和 fail2ban 的 Ubuntu 18.04。在 ufw 中，https 对所有人开放。我已经禁用了每个服务并重新启动了 apache，但没有成功。我还没有找到任何单独列出 github ip 的规则。但是我没有经验，如果它们存在，我可能不明白如何为它们寻找足够的深度。我认为简单地禁用这些服务就足以测试它们是否参与其中。

使用 tshark 检查来自 github

的传入 HTTPS POST 请求

tshark 显示在“Server Hello, Certificate, Server Key Exchange, Server Hello Done”之后，没有握手。从我的服务器到 github 有 4 或 5 次 [PSH,ACK] 重传，没有来自 github 的响应，然后 github 关闭连接。

这是我的 SSL 证书的问题吗？

我的主 domain.com 有一个不适用于任何子域的 Comodo SSL 证书。我的 staging.domain.com 有一个有效的 Let's Encrypt SSL 证书。

当我运行 openssl s_client -showcerts -servername staging.domain.com -connect staging.domain.com:443 </dev/null我获得了属于 staging.domain.com 的 Let's Encrypt 证书

但是当我运行 openssl s_client -showcerts -connect staging.domain.com:443 </dev/null我获得了属于主 domain.com 的 Comodo 证书

可能github的webhook服务不能处理SNI？ (主域和子域 Apache 虚拟主机都包括 <ServerName ... > )

然后我禁用了 Comodo SSL 证书，并扩展了 Let's Encrypt 证书以包括 domain.com 和 staging.domain.com，并重新启动 Apache。仍然是来自 github 的“服务超时”。

github 不喜欢 Let's Encrypt 吗？我从 Comodo 订购了 30 天的免费证书，并将其应用于 staging.domain.com。没运气。

当我通过 https://www.ssllabs.com/ssltest 运行 staging.domain.com 时，它显示了 Let's Encrypt 证书，但有趣的是，在其下方，它显示了“Certificate #2”，这是 domain.com 的 Comodo 证书。而且由于域名不匹配，该证书被标记为大量红色警告。这是异常行为吗，我是否应该在访问(或分析)staging.domain.com 时找到一种无法检测到 domain.com 证书的方法？

在这一点上，我完全没有想法。我将不胜感激任何和所有的指导。这也是我的第一个 SO 问题，我也愿意就我的问题礼仪提出建议。

编辑 1:激活 webhook 推送事件时，这里是 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" 的输出(这些是 github 的 webhook IP):

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 帧似乎是 SSL 证书信息从我的服务器到 github 的初始传输。然后第 7 帧到第 11 帧是相同信息的 5 次重传，都没有回复。之后，github 只是启动关闭连接，没有错误。

编辑 2:我已经尝试使用默认的 Apache 和自签名 SSL 证书启动测试服务器。同样的问题。我还尝试在我的面向公众的网站上测试 webhook，该网站具有功能齐全、签名和付费的 Comodo 证书。同样的问题。

Answer 1

Github 支持人员花了几个星期才回复我，但最终他们能够确定问题所在:

"the MTU on your server is set very high and you're not accepting ICMP defragmentation responses (MSS=8860)."

打字 ip addr显示网络接口(interface)的 mtu 设置(在本例中为 ens3)为 8900。这是我部署的 Ubuntu 20.04 镜像的开箱即用设置。
按照我在互联网上找到的说明，我使用了 ping -s XXXX -c1 distrowatch.com并发现任何高于 1452 的 XXXX 数字都会导致 100% 的丢包率。
header 的 1452 + 28 字节意味着 1480 mtu 设置应该可以工作。
由前文知 ip addr网络接口(interface)为 ens3 的命令，我输入了 sudo ip link set dev ens3 mtu 1480并尝试重新交付 github webhook。瞧，它奏效了。
在我的系统上，网络配置不在 /etc/network/interfaces但在 /etc/netplan/50-cloud-init.yaml .因此，为了使 mtu 永久更改，我对该文件进行了备份，然后将其 mtu 从 8900 编辑到 1480。最后，github webhook 起作用了!