与openssl签署的证书？

 

我将https支持添加到嵌入式Linux设备。 我试图通过以下步骤生成自签名证书： 

openssl req -new > cert.csr
openssl rsa -in privkey.pem -out key.pem
openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 1001
cat key.pem>>cert.pem

这有效，但我得到一些错误，例如，谷歌浏览器：

这可能不是您正在寻找的网站！
该网站的安全证书不被信任！

我错过了什么吗？ 这是建立自签名证书的正确方法吗？

你可以用一个命令来完成这个任务： 

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

如果您不想用密码保护您的私钥，也可以添加-nodes ，否则会提示您输入“至少4个字符”的密码。 days参数（365）可以用任何数字替换以影响到期日期。 然后，它会提示您输入“国家/地区名称”之类的信息，但您可以按回车并接受默认值。

自签名证书未经任何第三方验证，除非您先将其导入浏览器。 如果您需要更多安全性，则应使用由CA签名的证书。

我错过了什么吗？ 这是建立自签名证书的正确方法吗？

它很容易创建一个自签名证书。 您只需使用openssl req命令。 创建一个可以被大量客户使用的浏览器和命令行工具可能会很棘手。

这很困难，因为浏览器有自己的一套要求，而且它们比IETF更具限制性。 浏览器使用的要求记录在CA /浏览器论坛上（请参阅下面的参考资料）。 这些限制出现在两个关键领域：（1）信任锚，（2）DNS名称。

现代浏览器（比如我们在2014/2015使用的warez）需要一个链接回信任锚点的证书，并且他们希望DNS名称在证书中以特定的方式呈现。 而且浏览器正在积极采用自签名服务器证书

某些浏览器并不会轻易导入自签名服务器证书。 事实上，你不能使用一些浏览器，比如Android的浏览器。 所以完整的解决方案就是成为你自己的权威。

在没有成为您自己的权力的情况下，您必须获得DNS名称才能为证书提供最大的成功机会。 但我会鼓励你成为你自己的权威。 它很容易成为你自己的权力，它会侧重所有的信任问题（谁比你更信任？）。

这可能不是您正在寻找的网站！
该网站的安全证书不被信任！

这是因为浏览器使用预定义的信任锚点列表来验证服务器证书。 自签名证书不会链接回受信任的锚点。

避免这种情况的最好方法是：

  • 创建您自己的权限（即成为CA）
  • 为服务器创建证书签名请求（CSR）
  • 使用您的CA密钥签署服务器的CSR
  • 在服务器上安装服务器证书
  • 在客户端上安装CA证书

    • 第1步 - 创建您自己的权限仅仅意味着使用CA: true创建一个自签名证书CA: true合适的密钥用法。 这意味着Subject和Issuer是相同的实体，CA在Basic Constraints中设置为true（它也应该被标记为关键），密钥用法是keyCertSign和crlSign （如果您使用的是CRL）以及Subject Key Identifier（SKI ）与机构密钥标识符（AKI）相同。

    要成为您自己的证书颁发机构，请参阅您如何使用您的证书颁发机构签署证书签名请求？ 堆栈溢出。 然后，将您的CA导入浏览器使用的信任库中。

    第2步到第4步大致就是您在使用Startcom或CAcert等CA获得服务时面向公众服务的服务器。 第1步和第5步让你避开第三方权威，并作为你自己的权威（谁比你更信任？）。

    避免浏览器警告的下一个最好的方法是信任服务器的证书。 但是一些浏览器，如Android的默认浏览器，不会让你这样做。 所以它永远不会在平台上工作。

    浏览器（以及其他类似用户代理）不信任自签名证书的问题将成为物联网（IoT）中的一个大问题。 例如，当您连接恒温器或冰箱进行编程时会发生什么？ 答案是，就用户体验而言，没有什么好的。

    W3C的WebAppSec工作组正在着手研究这个问题。 例如，请参阅Proposal：将HTTP标记为不安全。

    如何使用openssl创建自签名证书？

    下面的命令和配置文件会创建一个自签名证书（它还会显示如何创建签名请求）。 它们在某些方面与其他答案不同：用于自签名证书的DNS名称位于主题备用名称（SAN）中，而不是通用名称（CN）。

    DNS名称通过配置文件放置在SAN中，其行subjectAltName = @alternate_names （无法通过命令行执行）。 然后在配置文件中有一个alternate_names部分（你应该调整它以适应你的口味）： 

    [ alternate_names ]

DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       = 127.0.0.1

# IPv6 localhost
# DNS.8     = ::1

    将DNS名称放入SAN而非CN是非常重要的，因为IETF和CA /浏览器论坛都会指定这种做法。 他们还指定CN中的DNS名称已弃用（但不禁止）。 如果您在CN中放入DNS名称，则必须在CA / B策略下将其包含在SAN中。 所以你不能避免使用主题替代名称。

    如果您没有在SAN中放入DNS名称，则证书将无法在遵循CA /浏览器论坛准则的浏览器和其他用户代理下进行验证。

    相关：浏览器遵循CA /浏览器论坛政策; 而不是IETF的政策。 这是使用OpenSSL（通常在IETF之后）创建的证书有时不会在浏览器下（浏览器遵循CA / B）验证的原因之一。 它们是不同的标准，它们有不同的发行政策和不同的验证要求。

    创建一个自签名证书 （注意添加-x509选项）： 

    openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes 
    -keyout example-com.key.pem -days 365 -out example-com.cert.pem

    创建一个签名请求 （注意缺少-x509选项）： 

    openssl req -config example-com.conf -new -sha256 -newkey rsa:2048 -nodes 
    -keyout example-com.key.pem -days 365 -out example-com.req.pem

    打印自签名证书 ： 

    openssl x509 -in example-com.cert.pem -text -noout

    打印签名请求 ： 

    openssl req -in example-com.req.pem -text -noout

    配置文件（通过-config选项传递） 

    [ req ]
default_bits        = 2048
default_keyfile     = server-key.pem
distinguished_name  = subject
req_extensions      = req_ext
x509_extensions     = x509_ext
string_mask         = utf8only

# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
#   Its sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName         = Country Name (2 letter code)
countryName_default     = US

stateOrProvinceName     = State or Province Name (full name)
stateOrProvinceName_default = NY

localityName            = Locality Name (eg, city)
localityName_default        = New York

organizationName         = Organization Name (eg, company)
organizationName_default    = Example, LLC

# Use a friendly name here because its presented to the user. The server's DNS
#   names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
#   by both IETF and CA/Browser Forums. If you place a DNS name here, then you 
#   must include the DNS name in the SAN too (otherwise, Chrome and others that
#   strictly follow the CA/Browser Baseline Requirements will fail).
commonName          = Common Name (e.g. server FQDN or YOUR name)
commonName_default      = Example Company

emailAddress            = Email Address
emailAddress_default        = test@example.com

# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]

subjectKeyIdentifier        = hash
authorityKeyIdentifier  = keyid,issuer

# You only need digitalSignature below. *If* you don't allow
#   RSA Key transport (i.e., you use ephemeral cipher suites), then
#   omit keyEncipherment because that's key transport.
basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage  = serverAuth, clientAuth

# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]

subjectKeyIdentifier        = hash

basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage  = serverAuth, clientAuth

[ alternate_names ]

DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       = 127.0.0.1

# IPv6 localhost
# DNS.8     = ::1

    您可能需要为Chrome执行以下操作。 否则Chrome可能会抱怨通用名称无效（ ERR_CERT_COMMON_NAME_INVALID ）。 我不确定SAN中的IP地址与此例中的CN之间的关系。 

    # IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

    还有其他有关处理X.509 / PKIX证书中的DNS名称的规则。 有关规则，请参阅这些文档：

  • RFC 5280，Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件
  • RFC 6125，在传输层安全性（TLS）环境中使用X.509（PKIX）证书在Internet公钥基础结构内表示和验证基于域的应用服务标识
  • RFC 6797，附录A，HTTP严格传输安全性（HSTS）
  • RFC 7469，HTTP的公钥固定扩展
  • CA /浏览器论坛基线要求
  • CA /浏览器论坛扩展验证指南

    • 列出了RFC 6797和RFC 7469，因为它们比其他RFC和CA / B文档更具限制性。 RFC 6797和7469也不允许IP地址。

    下面是@ diegows的答案中所描述的选项，从文档中有更详细的描述： 

    openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX

    req

    PKCS＃10证书请求和证书生成工具。 

    -x509

    此选项输出自签名证书而不是证书请求。 这通常用于生成测试证书或自签名的根CA. 

    -newkey arg

    该选项会创建一个新的证书请求和一个新的私钥。 该论点采取几种形式之一。 rsa：nbits ，其中nbits是位数，生成大小为nbits的RSA密钥。 

    -keyout filename

    这给出了将新创建的私钥写入的文件名。 

    -out filename

    这指定默认情况下要写入的输出文件名或标准输出。 

    -days n

    当使用-x509选项时，它指定证书所需的天数。 默认值是30天。 

    -nodes

    如果指定了此选项，那么如果创建了私钥，它将不会被加密。

    文档实际上比上面更详细，我在这里总结了一下。

    链接地址: http://www.djcxy.com/p/16219.html

    上一篇: signed certificate with openssl?

    下一篇: Detecting gestures on multiple views in Android