在调查一个影响同时受到影响的代理集群的问题时，我发现在build立SSL连接时存在奇怪的行为。 现象的症状是，当出现冲击时，传出的HTTPS请求比平常要慢，我已经把它放慢了，以便完成SSL握手。 HTTP请求/连接不会以相同的方式受到影响。 这个问题似乎是由于TCP三次握手结束和代理发送Client Hello之间的延迟而导致的出站连接。 之后，握手正常完成，没有延迟。 以下是来自stream量捕获的一些示例： to api.twitter.com （延迟2.4秒）： 到graph.facebook.com （延迟28.4秒）： 即使在第二个例子中重传， Client Hello包也不应该花那么长时间才能出去。 一些事实/考虑： 这个问题在一天中的特定时间（大约1000小时和1700小时）暂时出现，影响所有主机并在30分钟内消失。 以后，同时 这将表明一个外部原因（networking，也许），但tcpdump输出似乎把责任放在本地服务器 CPU，负载，内存和其他所有监视的性能指标都是正常的 它会影响所有的SSL远程主机 影响连接随机，一些行为正常，但很多是非常缓慢的 吞吐量（握手后）似乎没有受到影响 一旦问题通过，SSL连接到相同的远程主机一直很快 testing用curl和openssl s_client connect ，结果相同 需要澄清的是： 这可能是什么原因造成了这样的拖延？ Wirehark可以欺骗我吗？ 还有什么其他的性能指标/统计/命令可以用来进一步排查延误的原因？ 是否有任何networking因素（MTU，接收缓冲区，碎片），可以certificate这种行为？ 我如何find证据来澄清是否是我的服务器外部的networking问题？ 软件版本 ： 红帽企业Linux服务器版本5.11（Tikanga） OpenSSL 0.9.8e-fips-rhel5 2008年7月1日 kernel 2.6.18-416.el5＃1 SMP Wed Oct 26 12:04:18 EDT 2016 x86_64 x86_64 x86_64 GNU / Linux […]
我试着用TLS1.3configurationnginx 1.11.12，但每次失败。 你能解释我如何使用nginx 1.11.12和openssl 1.1.0e？
以下是错误的详细信息。 任何帮助，将不胜感激。 谢谢 DKIM Signature Message contains this DKIM Signature: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=awp1.com; s=default; h=Content-Type:Mime-Version:Subject:From:To:Date:Sender:Reply-To: Message-ID:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=hjFILYWdG5vAk56ssyvqVvZtJ7 E3FqFYB9y1ssKz/UQfsZYByVm/GovpCDpymrEdqxiUzDhufi8U8hyCj0liKwBHzIWt7XNsrC+tv1M Jfu8EA4gt73ith7wL0p1LS+NXMmlaN3Efk7tKfNTnOjGJV1GHKidqCpYgHvZJ9WfOQPkQLvGJOw90 A/wXHcBEBT8o749pSyqh739boijJm0yViKtgXdjdYpUO4IDFehFQ93fUNAW9hOQaW+76QlRUibwD6 PkB86C1FzsRmKgVF+2oaRB1hK6tlZzEpw3PINqSFQks7ETk7qmx73qqkgvP5e5Q002NOSARYofjY2 6ABU1BzA==; Signature Information: v= Version: 1 a= Algorithm: rsa-sha256 c= Method: relaxed/relaxed d= Domain: awp1.com s= Selector: default q= Protocol: dns/txt bh= 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= h= Signed Headers: Content-Type:Mime-Version:Subject:From:To:Date:Sender:Reply-To: […]
我通过apt to 1.1.0f在ubuntu服务器（14.04 LTS）上进行了OpenSSL升级。 升级完成后，我尝试（重新）启动apache2。 然后这出现： * Starting Apache httpd web server apache2 * * The apache2 configtest failed. Output of config test was: apache2: Syntax error on line 140 of /etc/apache2/apache2.conf: Syntax error on line 3 of /etc/apache2/mods-enabled/ssl.load: Cannot load /usr/lib/apache2/modules/mod_ssl.so into server: /usr/lib/apache2/modules/mod_ssl.so: symbol X509_getm_notAfter, version OPENSSL_1_1_0 not defined in file libcrypto.so.1.1 with […]
我正在testing连接到RADIUS服务器的设备的WLANfunction。 此RADIUS服务器位于具有Raspbian Stretch的Raspberry Pi上，并使用FreeRADIUS 3.0和Hostapd。 一些EAP-TLStesting用例检查如果长时间使用“信任链”会发生什么情况。 长信任链是指由长链中间证书签名的公钥 。 现在，我面临的问题是，在一些testing案例中，FreeRADIUS在其日志中返回一个特定的错误： SSL说错误25：超过了path长度限制 其中一个testing用例如下所述： RADIUS证书文件： 证书： ServerCert – IM1 – RootCA （由Root签名的由IM1签名的公钥） 私钥： ServerKey CA证书： IM3 – IM2 – IM1 – RootCA链 （由IM3，IM2，IM1和RootCA组成的链） 客户端证书文件： 证书： ClientCert – IM3 – IM2 – IM1 – RootCA （ClientCert由IM3签名，由IM2签名，由IM签名 私钥： ClientKey CA证书： IM1 – RootCA链 （由IM1和RootCA组成的链） 当试图连接这个设置时，在客户端发送Hello之后，RADIUS服务器开始发送它的CA证书链而不是期望的服务器证书（使用Wireshark来查看）。 它也会抛出错误25。 而现在的问题是： 什么错误“SSL说错误25：path长度约束超出”是什么意思，这是否与信任链的长度有关？ 所描述的configuration是否合法？ 为什么服务器发送CA证书链而不是服务器证书？ […]
正如它所说，我该如何让内部CA签署CSR？ 这将适用于您不能轻易replace客户机的私钥的情况，因此首选过程使用CSR的方式。 这甚至有可能吗？
我使用openssl req -new -newkey rsa:65536 > server.cert.csr创build了我的私钥和证书请求。 这花了一些分钟，并产生了2个文件。 然后我使用openssl rsa -in privkey.pem -out server.cert.key解密我的私钥 现在我想使用openssl x509 -in server.cert.csr -out server.cert.crt -req -signkey server.cert.key -days 365自签名证书，但是这会导致错误： Signature did not match the certificate request 我用同样的过程使用较小的键（只有4096位），然后工作。 有没有办法得到一个65536bit长的自签名密钥？ 这到底是什么问题还是只是一个错误？ 我相信我没有混用私钥或证书请求。
我在CA和所有证书最初以.pfx格式提供的地方工作。 我能够成功地将pfx转换为key / pem或key / crt，这取决于我的需要。 在本周进行testing时，我发现转换过程不会覆盖证书上的SAN。 有没有办法做到这一点，而不必手动configuration包含SAN的configuration文件？ 这是我现在正在做的转换从pfx： openssl pkcs12 -in <pfx> -out <key> -nocerts -nodes openssl rsa -in <key> -out <key> openssl pkcs12 -in <pfx> -out <pem> -nokeys -clcerts
在networking上有许多问题，人们在设置内部networking上使用自签名证书方面有困难。 只是要链接几个： 让Chrome接受自签名的本地主机证书 Chrome接受自签名本地主机证书 在Chrome 58中生成一个openssl的自签名证书 StartCom证书错误：ERR_CERT_AUTHORITY_INVALID 我经历了每一个，但直到不能摆脱(net::ERR_CERT_COMMON_NAME_INVALID). 错误。 步骤如下： 服务器上的密钥和证书生成 openssl req \ -newkey rsa:2048 \ -x509 \ -nodes \ -keyout file.key \ -new \ -out file.crt \ -subj /CN=Hostname \ -reqexts SAN \ -extensions SAN \ -config <(cat /etc/ssl/openssl.cnf \ <(printf '[SAN]\nsubjectAltName=DNS:192.168.0.1')) \ -sha256 \ -days 3650 设置服务器进程（apache）使用新生成的证书和密钥文件进行安全连接 通过Chrome开发工具导航到https://192.168.0.1:3122并使用导出选项将证书文件从服务器导出到客户端 将CA添加到已知证书颁发机构（在Fedora 26上）列表中 certutil sudo […]
我没有很多configurationSSL的经验，所以很有可能我错过了一些东西，但是如何在没有通过负载均衡器的情况下为EC2configurationSSL呢？ 这是用于与第三方API进行通信的服务器，要求我们将我们的IP地址白名单，我们不能使用DNS。 我遵循这个指南https://www.digitalocean.com/community/tutorials/how-to-create-an-ssl-certificate-on-nginx-for-ubuntu-14-04但到目前为止，我的浏览器显示一个证书不同于我正在使用的那个。 也许它caching不知何故？ 这是我正在尝试使用的那个 – —–BEGIN CERTIFICATE—– MIIDDzCCAfegAwIBAgIJAMkWNQsBzPFcMA0GCSqGSIb3DQEBCwUAMB4xHDAaBgNV BAMMEyouc3RnLmF1dG9icmFpbi5jb20wHhcNMTcxMTAzMDIwNzIzWhcNMjIxMTAy MDIwNzIzWjAeMRwwGgYDVQQDDBMqLnN0Zy5hdXRvYnJhaW4uY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA15PhjQTHi6o+2TCAd/dUpZzR1C/ucRfk 8SGr+2Zf/t0L3nNWt01M0EiaDpzqelkTHErwOAyRVWOUAeL/kk2SPqxb1y+mGPUN TWvKb/UWpaXTuAHmrTngpQaSq8mxxGXlHH/GB664kNhhmQxoCCoBGN/CsDmCrvGw EWL8rYVPppwiI9yury+XT5GqDEslR2+cSLp9FuuMGrFwwffw4xSCGr8kBeEY4VIr 8gW8E4MBFE37R4e6MhcCTJ2XuNDR69ZuCLM3IC3tiEzf/HmABcoI0/SbeqT/8WJX 9vIu2uoDmLn+Ae+QWEN/hzX5ER3lgBquT4OifBD/9KVJ1rff4hk9FQIDAQABo1Aw TjAdBgNVHQ4EFgQUUoh2YRTx/ouZlYYCfdRCZycC6EUwHwYDVR0jBBgwFoAUUoh2 YRTx/ouZlYYCfdRCZycC6EUwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQsFAAOC AQEAPSfIYBVVbueHgGLiFuBAWLdROA7a2P3SQsZcNsj1reSkPxJ0YB8g4fdyUNwp wws+SWSBZwkmriXE+NFuECV8uln1OgYcUOmmcT9YT0eNQih9lLq/UtYtq5aWYJR/ 0pwfGZ6kasHFOLdcN4SgKloqvJ4wJbt9FwpPpfVQSfh9RNEodMlDTAZQ+w2nXPHQ VygDrCEle6VVTEzfRiTGP6JB+E4RpDeW1ECpvp1WrNiwEgSbhW3Ek54AK/stQweQ QYE7OtiFEQtEQiqgu4gXfKjNawqwwu5sb22ot7LvgDgVudscXV40PzFAJzFEOvCr xJtJ0+JZ37VqFTLmJidH+Hz3Ng== —–END CERTIFICATE—–