nginx SSL没有起跑线:期望值:可信任证书 [英] nginx SSL no start line: expecting: TRUSTED CERTIFICATE

查看:294
本文介绍了nginx SSL没有起跑线:期望值:可信任证书的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我没有主意,需要帮助!

I'm out of ideas and I need help please!

我使用Openssl创建SSL:

I create my SSL using Openssl with this:

openssl req -x509 -newkey rsa:4096 -sha256 -nodes -keyout key.pem -out cert.pem -days 3650

cert.pem看起来像这样:

The cert.pem looks like this:

-----BEGIN CERTIFICATE-----
cert
-----END CERTIFICATE-----

密钥。 pem看起来像这样:

The key.pem looks like this:

-----BEGIN PRIVATE KEY-----
key
-----END PRIVATE KEY-----

在docker-compose中,我有证书/密钥发送到etc / nginx / ssl /...

In docker-compose I have the cert/key sent to etc/nginx/ssl/...

volumes:
  - ./sites:/etc/nginx/conf.d
  - ./conf/nginx.conf:/etc/nginx/nginx.conf
  - ./ssl/cert.pem:/etc/nginx/ssl/cert.pem
  - ./ssl/key.pem:/etc/nginx/ssl/key.pem

在nginx中,我是这样添加的:

In nginx I have it added like this:

  listen    443 ssl;
  server_name       localhost;
  ssl_certificate   ssl/cert.pem;
  ssl_certificate_key   ssl/key.pem;

启动docker-compose时,nginx出现此错误:

When I start up docker-compose, I get this error with nginx:

web_1    | 2018/08/17 16:38:47 [emerg] 1#1: PEM_read_bio_X509_AUX("/etc/nginx/ssl/cert.pem") failed (SSL: error:0906D06C:PEM routines:PEM_read_bio:no start line:Expecting: TRUSTED CERTIFICATE)
web_1    | nginx: [emerg] PEM_read_bio_X509_AUX("/etc/nginx/ssl/cert.pem") failed (SSL: error:0906D06C:PEM routines:PEM_read_bio:no start line:Expecting: TRUSTED CERTIFICATE)

我已经为此工作了几天,但我不确定为什么会不断收到此错误。我尝试将其设置为crt / key而不是.pem,但出现了相同的错误。如果我只是一起删除ssl,则服务器工作正常,但我非常需要SSL。求助!

I've been working on this for several days now and I'm not sure why I keep getting this error. I've tried making it crt/key instead of .pem and I get the same error. If I just remove ssl all together the server works fine, but I need SSL very badly. Pleeeaaase help!

推荐答案

一旦以PEM编码,正常证书将如下所示:

A "normal" certificate, once encoded in PEM will look like this:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

... DER 结构的Base64编码)

(the ... is Base64 encoding of a DER structure)

通常(使用相关的密钥,通常在单独的文件中)

This is normally (with the associated key, typically in separate file) the thing needed by any TLS enabled application when it wants to show its identity to the remote end.

作为附带说明,由于它似乎很流行(错误),因此,任何启用TLS的应用程序都需要它。文件名本身(包括扩展名)本身对内容的工作(或不工作)状态没有任何影响。您可以将文件命名为 foobar.42 buzz.666 ,如果文件内容有效,它们也将正常工作。 ..当然,人工维护会比较困难,因此惯例通常使用 .crt 来获取证书(或 .cert (用于基于非DOS的受限环境), .key (用于密钥文件),通常使用站点名称(对于网站)或名称的一部分,例如 example.com.crt
但是,这些只是一组可能的约定,需要这些文件的任何程序都不关心名称,而只关心内容。
有些人也在使用 .pem 扩展名。

As a side note, since it seems to be popular (wrong) belief, the filename by itself, including the extension, has explicitly no consequences on the working (or not) status of the content. You can name your files foobar.42 and buzz.666 and if their content is valid they will work as well... of course maintenance by the human would be harder, hence the convention of using often .crt for a certificate (or .cert for non-DOS based constrained environments) and .key for a keyfile, and using typically the site name (for a website) or part of it for the name, such as example.com.crt. But again, those are only one possible set of conventions, and any program needing these files do not care about the name, just the content. Some are using the .pem extension also.

请参见 https://en.wikipedia.org/wiki/X.509#Certificate_filename_extensions 的上述所有方面都很好讨论/介绍选项。

See https://en.wikipedia.org/wiki/X.509#Certificate_filename_extensions for all the above it has a good discussion/presentation of options.

现在,在您的情况下,错误消息告诉您它期望这样编写内容:

Now in your case the error message was telling you it expected to have a content written as such:

-----BEGIN TRUSTED CERTIFICATE-----
...
-----END TRUSTED CERTIFICATE-----

唯一的区别是添加的 TRUSTED 关键字。但是为什么以及何时发生呢?

the only difference being the added TRUSTED keyword. But why, and when does it happen?

一个证书颁发机构通过一个或多个中间人对证书进行签名。这将建立起一个根证书颁发机构的信任链,在该证书中颁发者等于主题,该证书会自己签名。

A certificate is signed by one "certificate authority" through one or more intermediates. This builds a chain of trust up to a root certificate, where the issuer is equal to the subject, this certificate signs itself.

您自己生成了证书,所以这是自签名证书,在技术上与CA证书没有区别,只是默认情况下,没有任何系统(包括您自己的系统)会在没有特定配置的情况下信任该证书。

You generated your certificate yourself, so this is a "self-signed" certificate, indistinguishable technically from a CA certificate, except that no system by default, including your own, will give trust to such certificate without specific configuration.

这基本上是错误消息告诉您的内容:应用程序说它正在基于您无法验证(因为它是自签名)的配置加载证书,与此同时,您也没有明确配置它以信任它。

This is basically what the error message tells you: the application says it is loading a certificate based on your configuration that it can not validate (because it is self signed) and at the same time you did not explicitely configure it to trust it.

这可能因应用程序或其版本而异,因为该指南位于 https://www.digitalocean.com/community/tutorials/how-创建自己的签名d-ssl-certificate-for-nginx-in-ubuntu-16-04 与您所做的事情基本相同,但是没有显示证书的内容。

This may be different depending on the application or its version, because the guide at https://www.digitalocean.com/community/tutorials/how-to-create-a-self-signed-ssl-certificate-for-nginx-in-ubuntu-16-04 does basically the same thing as you and it works, but without showing the content of the certificate.

在您的 openssl 调用中,如果添加 -trustout ,则会生成 BEGIN可信证书,而不是。默认情况下,也可能会发生这种情况,具体取决于系统上openssl的安装/配置方式。相反,您具有 -clrtrust
请在openssl x509 命令的信任设置部分: //www.openssl.org/docs/man1.1.0/apps/x509.html rel = noreferrer> https://www.openssl.org/docs/man1.1.0/apps/x509.html

In your openssl call, if you add -trustout it will generate BEGIN TRUSTED CERTIFICATE instead of BEGIN CERTIFICATE. This may happen by default also, depending on how openssl is installed/configured on your system. On the contrary, you have -clrtrust. See the "Trust Settings" section of the openssl x509 command at https://www.openssl.org/docs/man1.1.0/apps/x509.html

这篇关于nginx SSL没有起跑线:期望值:可信任证书的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆