In short, you (probably) can't use it for that. But we need to check to be sure.
Background
As you know, SSL is used to secure the communication between two systems, one a server and the other a client (well, for the purposes of this communication link anyway). For the code that sits on initiating, client end of the communication channel to know that it's talking to the right server, it needs not just to have secure communication but also the identity of the server. (Without that, DNS spoofing or any number of IP-level tricks would be utterly massive problems.) This is where certificates come in.
Servers have a cryptographic identity (a public/private key-pair) that they use as part of the boot-strapping of the SSL connection which proves who they are. The public part of that is told to anyone who asks, and the server proves that it has private part through the fact that it can do the key-pair based cryptography (basically, that's mathematical magic, a.k.a. number theory). Then, all the client has to do to know whether to trust the connection is to work out whether they trust the identity stamped into the public key. This can either be by having been previously told directly “trust this certificate” or by the fact that it was digitally signed by someone it trusts (which is how the Certificate Authority system works).
A certificate is basically the public key of a key-pair, at least one digital signature, plus additional information. Examples of the additional information that could be there are the name of the host for which this is a certificate, the period of time for which the certificate is valid, who the administrative contact is, or where to go to find out whether the certificate has been withdrawn early. There are many other options.
What to do with a bare certificate?
With a bare certificate (in PEM format, as you say) all you can do is add it to your collection of trusted certificates or look at the information encoded within the certificate. So we'll start by looking at the information. For that, we use the openssl program (which has a horrible command line interface):
openssl x509 -in thecert.pem -text -noout
That will splurge a whole bunch of information out. The most important part is the “Subject” field; what or who is this certificate talking about? Since this is about HTTPS (which imposes a few extra constraints of its own) we should check whether that contains a hostname of some kind, and what host it is talking about.
Now you have the information to be able to figure out what's going on.
If the whole certificate matches up (especially the digital signature) with what you've already got deployed on your own HTTPS-enabled server, then your customer has just sent you back something you already have. Ho hum.
If the hostname is for a machine that you control and your customer doesn't (e.g., your development server) then your customer has just tried to get a certificate on your behalf. That's a bit of a no-no, but I advise taking it well — especially if you've not yet set up HTTPS. For the purposes of testing, you can get your own single-host certificate (that signs a public key where you've generated the private key yourself) for next to nothing. It's also a reasonable expense to bill your customer.
If the hostname is for the machine where the customer has told you they want to deploy your code in production, then they've just given you something you don't really need. I suppose it might be relevant for client code that wants to connect to the deployment server, but that's not as useful as all that; certificates expire, stuff moves round, and all sorts of things happen in production that can mean that it is useful to issue a new server certificate. Having to push updates to all the deployed clients just because someone accidentally deleted the server certificate without keeping a backup (a more common thing than you might wish) would Truly Suck. Thus, the deployment host certificate is not something you should need.
If its none of these, and it's a long lived certificate (check the Validity field from the information you printed out before) then it might actually be the certificate of a back end service that you're supposed to talk to. Or the certificate of a private CA that signs all the certificates of the back-end services that you talk to. (Are you doing this? I don't know, and I don't know your app, but it's quite possible.) In this case you would add the certificate to the list of trusted certificates in your code (the exact way depends on how your code handles SSL) and this is the only use I can think of for a certificate at the stage you're at.
Trouble is, I don't think (on the basis of what you write) that it's all that likely. Talk to your customer; security is something where you want to get it right, and use and trust of certificates is key to that.
If it's truly none of the above, talk to the customer and say you're a bit confused. I know I am in this case!
发布评论
评论（1）
简而言之，你（可能）不能用它来实现这一点。但我们需要检查一下才能确定。
背景
如您所知，SSL 用于保护两个系统之间的通信，一个是服务器，另一个是客户端（好吧，无论如何，为了此通信链接的目的）。为了使位于通信通道的发起客户端的代码知道它正在与正确的服务器通信，它不仅需要具有安全的通信，还需要服务器的身份。 （如果没有这个，DNS 欺骗或任何数量的 IP 级技巧将是一个非常大的问题。）这就是证书的用武之地。
服务器有一个加密身份（公钥/私钥对），它们将其用作启动的一部分-SSL 连接的捆绑，证明他们是谁。其中的公共部分被告知任何询问的人，并且服务器通过它可以执行基于密钥对的加密技术（基本上，这是数学魔法，又名数论）来证明它具有私有部分。然后，客户端要知道是否信任该连接所需要做的就是确定他们是否信任标记在公钥中的身份。这可以是通过之前直接被告知“信任此证书”，也可以是通过它是由其信任的人进行数字签名的事实（这就是证书颁发机构系统的工作方式）。
证书基本上是密钥对的公钥、至少一个数字签名以及附加信息。可能存在的附加信息的示例包括该证书所属的主机的名称、证书的有效期限、管理联系人是谁，或者去哪里查找该证书是否已生效。早被撤回了。还有很多其他选择。
裸证怎么办？
对于裸证书（如您所说，采用 PEM 格式），您所能做的就是将其添加到受信任的证书集合中，或者查看证书中编码的信息。因此，我们将从查看信息开始。为此，我们使用
openssl程序（它有一个可怕的命令行界面）：这会浪费大量信息。最重要的部分是“
Subject”字段；这张证书在谈论什么或谁？由于这是关于 HTTPS（它本身施加了一些额外的约束），我们应该检查它是否包含某种主机名，以及它正在谈论什么主机。现在您掌握了信息，可以弄清楚发生了什么。
如果整个证书（尤其是数字签名）与您自己的启用 HTTPS 的服务器上已部署的证书相匹配，则您的客户刚刚向您发回了您已有的证书。呵呵。
如果主机名是您控制的机器，而您的客户不控制（例如，您的开发服务器），那么您的客户只是尝试代表您获取证书。这有点禁忌，但我建议好好对待它——特别是如果您尚未设置 HTTPS。出于测试目的，您几乎可以免费获得自己的单主机证书（该证书对您自己生成私钥的公钥进行签名）。向客户收取费用也是一笔合理的费用。
如果主机名是客户告诉您他们想要在生产中部署您的代码的机器，那么他们只是给了您一些您并不真正需要的东西。我想它可能与想要连接到部署服务器的客户端代码相关，但这并不那么有用；证书过期、内容流动以及生产中发生的各种情况都可能意味着颁发新的服务器证书很有用。仅仅因为有人不小心删除了服务器证书而没有保留备份（比您希望的更常见的事情）就必须将更新推送到所有已部署的客户端，这真的很糟糕。因此，部署主机证书不是您应该需要的。
如果不是这些，并且它是一个长期存在的证书（从您之前打印的信息中检查
Validity字段），那么它实际上可能是您的后端服务的证书re 应该交谈。或者是签署您所访问的后端服务的所有证书的私有 CA 的证书。 （你在这样做吗？我不知道，我也不了解你的应用程序，但这很有可能。）在这种情况下，你可以将证书添加到你的应用程序中的受信任证书列表中代码（确切的方式取决于您的代码如何处理 SSL），这是我能想到的在您所处阶段证书的唯一用途。问题是，我认为（根据你所写的内容）这不太可能。与您的客户交谈；安全性是您想要做好的事情，而证书的使用和信任是实现这一点的关键。
如果确实不是以上任何一种情况，请与客户交谈并表示您有点困惑。我知道我就是这种情况！
In short, you (probably) can't use it for that. But we need to check to be sure.
Background
As you know, SSL is used to secure the communication between two systems, one a server and the other a client (well, for the purposes of this communication link anyway). For the code that sits on initiating, client end of the communication channel to know that it's talking to the right server, it needs not just to have secure communication but also the identity of the server. (Without that, DNS spoofing or any number of IP-level tricks would be utterly massive problems.) This is where certificates come in.
Servers have a cryptographic identity (a public/private key-pair) that they use as part of the boot-strapping of the SSL connection which proves who they are. The public part of that is told to anyone who asks, and the server proves that it has private part through the fact that it can do the key-pair based cryptography (basically, that's mathematical magic, a.k.a. number theory). Then, all the client has to do to know whether to trust the connection is to work out whether they trust the identity stamped into the public key. This can either be by having been previously told directly “trust this certificate” or by the fact that it was digitally signed by someone it trusts (which is how the Certificate Authority system works).
A certificate is basically the public key of a key-pair, at least one digital signature, plus additional information. Examples of the additional information that could be there are the name of the host for which this is a certificate, the period of time for which the certificate is valid, who the administrative contact is, or where to go to find out whether the certificate has been withdrawn early. There are many other options.
What to do with a bare certificate?
With a bare certificate (in PEM format, as you say) all you can do is add it to your collection of trusted certificates or look at the information encoded within the certificate. So we'll start by looking at the information. For that, we use the
opensslprogram (which has a horrible command line interface):That will splurge a whole bunch of information out. The most important part is the “
Subject” field; what or who is this certificate talking about? Since this is about HTTPS (which imposes a few extra constraints of its own) we should check whether that contains a hostname of some kind, and what host it is talking about.Now you have the information to be able to figure out what's going on.
If the whole certificate matches up (especially the digital signature) with what you've already got deployed on your own HTTPS-enabled server, then your customer has just sent you back something you already have. Ho hum.
If the hostname is for a machine that you control and your customer doesn't (e.g., your development server) then your customer has just tried to get a certificate on your behalf. That's a bit of a no-no, but I advise taking it well — especially if you've not yet set up HTTPS. For the purposes of testing, you can get your own single-host certificate (that signs a public key where you've generated the private key yourself) for next to nothing. It's also a reasonable expense to bill your customer.
If the hostname is for the machine where the customer has told you they want to deploy your code in production, then they've just given you something you don't really need. I suppose it might be relevant for client code that wants to connect to the deployment server, but that's not as useful as all that; certificates expire, stuff moves round, and all sorts of things happen in production that can mean that it is useful to issue a new server certificate. Having to push updates to all the deployed clients just because someone accidentally deleted the server certificate without keeping a backup (a more common thing than you might wish) would Truly Suck. Thus, the deployment host certificate is not something you should need.
If its none of these, and it's a long lived certificate (check the
Validityfield from the information you printed out before) then it might actually be the certificate of a back end service that you're supposed to talk to. Or the certificate of a private CA that signs all the certificates of the back-end services that you talk to. (Are you doing this? I don't know, and I don't know your app, but it's quite possible.) In this case you would add the certificate to the list of trusted certificates in your code (the exact way depends on how your code handles SSL) and this is the only use I can think of for a certificate at the stage you're at.Trouble is, I don't think (on the basis of what you write) that it's all that likely. Talk to your customer; security is something where you want to get it right, and use and trust of certificates is key to that.
If it's truly none of the above, talk to the customer and say you're a bit confused. I know I am in this case!