Puma 可以从变量中读取 TLS 证书吗?
Can Puma read TLS certificates from a variable?
我们在 Windows 中有一个 Rails 应用程序 运行 使用 Puma。到目前为止,我们已经将 SSL/TLS 证书存储在文件系统上,这似乎是一般标准,以及 Puma is designed 在启动时接收该数据的方式。
我们只想在磁盘上保留一个加密的 PKCS#12 文件 (.12),它包含所有证书数据(一个或多个证书和私钥),在 puma 启动期间提取特定证书放入变量中,然后将其直接输入到 Puma ssl_bind 命令中。
所以我想弄清楚 Puma 是否可以接受保存证书数据的变量,而不是提供指向纯文本文件的预期 cert_path 和 key_path .
我已经尝试了几种不同的方法来用变量替换文件路径,但到目前为止我只遇到错误(参见下面的示例)。我已经从文件系统中输出了证书密钥,它们看起来和我一样。我已经阅读了其他一些相关的 SO 线程,这些线程建议我可能需要添加换行符或以其他方式稍微操纵我的变量中的数据,但到目前为止,这种思路让我感到困惑,我不确定它是否真的适合我的场景.我认为这归结为 ssl_bind 需要一个文件路径,并且很可能 运行 幕后的“文件打开”逻辑。是不是根本不支持直接拿?
以下是当今有效的示例:
# tls.key and tls.crt are already sitting on filesystem
ssl_bind '0.0.0.0', '443', {
key: 'certs/tls.key',
cert: 'certs/tls.crt',
no_tlsv1: true,
no_tlsv1_1: true,
verify_mode: 'none'
}
这是我们想要做的事情的例子
require 'openssl'
# get p12 password out of secrets at runtime
p12_password = Rails.application.credentials.p12[:password].to_s
# open encrypted p12 file
p12 = OpenSSL::PKCS12.new(File.binread('certs/tls.p12'), p12_password)
# pull out certificate and key from p12
leafkey = p12.key.to_pem
leafcertificate = p12.certificate.to_pem
ssl_bind '0.0.0.0', '443', {
key: leafkey,
cert: leafcertificate,
no_tlsv1: true,
no_tlsv1_1: true,
verify_mode: 'none'
}
我们从上面收到的错误是:
C:/Ruby27-x64/lib/ruby/gems/2.7.0/gems/puma-4.3.8/lib/puma/minissl.rb:209:in `key=': No such key file '-----BEGIN EC PRIVATE KEY-----MDECAQEEIBccaYhSLodf 4TRzzWkOE5rr8t Ul0oQHcjYmmoiuvloAoGCCqGSM4jdu73-----END EC PRIVATE KEY-----' (ArgumentError)
这是有效的 EC 密钥数据,但 Puma/ssl_bind 看起来很困惑(不足为奇)它不是包含此数据的磁盘文件的预期路径。 这样可以骗Puma直接接受吗?
感谢您阅读并花时间表达您的任何想法!
此要求是在 this PR
中作为增强功能添加的
到目前为止,我似乎能够毫不费力地将 Puma 从 4.3.8 直接更新到 5.6.2。我们确实需要将 2 个选项更新到 *_pem 版本,即
cert 变为 cert_pem 和
key 变为 key_pem
有了这个,它就可以正常工作了。
示例 运行 美洲狮 5.6.2:
require 'openssl'
# using cleartext password for testing/simplicity
p12 = OpenSSL::PKCS12.new(File.binread('certs/tls.p12'), "1234")
leafcertificate = p12.certificate.to_pem
leafkey = p12.key.to_pem
ssl_bind '0.0.0.0', '443', {
cert_pem: leafcertificate,
key_pem: leafkey,
no_tlsv1: true,
no_tlsv1_1: true
}
个人经验教训:我应该优先挖掘 Puma 存储库:拉取请求、问题等
我们在 Windows 中有一个 Rails 应用程序 运行 使用 Puma。到目前为止,我们已经将 SSL/TLS 证书存储在文件系统上,这似乎是一般标准,以及 Puma is designed 在启动时接收该数据的方式。
我们只想在磁盘上保留一个加密的 PKCS#12 文件 (.12),它包含所有证书数据(一个或多个证书和私钥),在 puma 启动期间提取特定证书放入变量中,然后将其直接输入到 Puma ssl_bind 命令中。
所以我想弄清楚 Puma 是否可以接受保存证书数据的变量,而不是提供指向纯文本文件的预期 cert_path 和 key_path .
我已经尝试了几种不同的方法来用变量替换文件路径,但到目前为止我只遇到错误(参见下面的示例)。我已经从文件系统中输出了证书密钥,它们看起来和我一样。我已经阅读了其他一些相关的 SO 线程,这些线程建议我可能需要添加换行符或以其他方式稍微操纵我的变量中的数据,但到目前为止,这种思路让我感到困惑,我不确定它是否真的适合我的场景.我认为这归结为 ssl_bind 需要一个文件路径,并且很可能 运行 幕后的“文件打开”逻辑。是不是根本不支持直接拿?
以下是当今有效的示例:
# tls.key and tls.crt are already sitting on filesystem
ssl_bind '0.0.0.0', '443', {
key: 'certs/tls.key',
cert: 'certs/tls.crt',
no_tlsv1: true,
no_tlsv1_1: true,
verify_mode: 'none'
}
这是我们想要做的事情的例子
require 'openssl'
# get p12 password out of secrets at runtime
p12_password = Rails.application.credentials.p12[:password].to_s
# open encrypted p12 file
p12 = OpenSSL::PKCS12.new(File.binread('certs/tls.p12'), p12_password)
# pull out certificate and key from p12
leafkey = p12.key.to_pem
leafcertificate = p12.certificate.to_pem
ssl_bind '0.0.0.0', '443', {
key: leafkey,
cert: leafcertificate,
no_tlsv1: true,
no_tlsv1_1: true,
verify_mode: 'none'
}
我们从上面收到的错误是:
C:/Ruby27-x64/lib/ruby/gems/2.7.0/gems/puma-4.3.8/lib/puma/minissl.rb:209:in `key=': No such key file '-----BEGIN EC PRIVATE KEY-----MDECAQEEIBccaYhSLodf 4TRzzWkOE5rr8t Ul0oQHcjYmmoiuvloAoGCCqGSM4jdu73-----END EC PRIVATE KEY-----' (ArgumentError)
这是有效的 EC 密钥数据,但 Puma/ssl_bind 看起来很困惑(不足为奇)它不是包含此数据的磁盘文件的预期路径。 这样可以骗Puma直接接受吗?
感谢您阅读并花时间表达您的任何想法!
此要求是在 this PR
中作为增强功能添加的到目前为止,我似乎能够毫不费力地将 Puma 从 4.3.8 直接更新到 5.6.2。我们确实需要将 2 个选项更新到 *_pem 版本,即
cert 变为 cert_pem 和 key 变为 key_pem
有了这个,它就可以正常工作了。
示例 运行 美洲狮 5.6.2:
require 'openssl'
# using cleartext password for testing/simplicity
p12 = OpenSSL::PKCS12.new(File.binread('certs/tls.p12'), "1234")
leafcertificate = p12.certificate.to_pem
leafkey = p12.key.to_pem
ssl_bind '0.0.0.0', '443', {
cert_pem: leafcertificate,
key_pem: leafkey,
no_tlsv1: true,
no_tlsv1_1: true
}
个人经验教训:我应该优先挖掘 Puma 存储库:拉取请求、问题等