我可以将自签名 SSL 证书用于商业目的吗？
我正在制作一个服务器客户端以使用 ssl 进行注册和登录过程。
（如果重要的话，这是针对 iPhone 的）
我刚刚开始研究什么是 ssl 以及如何使用它，并且
看到这个过程中有一个证书可以购买或自签名。
如果我在网络服务器中使用自签名证书，网络浏览器会警告该证书是自签名的，据我所知。
但是如果我在常规应用程序中使用 TCP（不是 http）（特别是 iPhone）使用自签名证书，会发生什么。
我只想注册/登录 信息（他们的密码）是安全的，
并希望使用自签名 证书就可以了 目的。但我还需要做 确保这不会导致“不可信 证书-警报”类型 在应用程序中使用时中断 除了网络浏览器之外。
- 编辑
我知道“不可信证书警报”是说客户端不应该信任该服务器。
但在我的情况下，客户端不需要向服务器进行身份验证。
服务器只需要以安全的方式获取客户端的密码即可。
I'm making a server-client to use ssl for sign up and login process.
(and this is for iphone if it matters)
I just started looking at what ssl is and how to use it, and
saw there is a certificate in the process which can be bought or self-signed.
If I use self-signed certificate in web server, web browser would alert that cert is self-signed, that I understand.
But what would happen if I use self-signed certificate in regular application with tcp(not http), specifically iphone.
I just want to make the signup/login
info(their password) to be secure,
and hoping that using self-signed
certificate would be ok for this
purpose. But I also need to make
sure this won't cause "not trusted
certificate - alert" type of
interruption when used in application
other than a web browser.
- Edit
I understand that "not trusted certificate alert" is saying client shouldn't trust this server.
But in my situation, client doesn't need to authenticate with the server.
The server just needs to get client's password in a secure way.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这就是受信任的签名机构的全部要点 - 由其他人签名的任何内容都应该发出安全警报。所以，不，没有有用的方法来覆盖它（除非您可以控制客户端计算机 - 例如用于公司内部站点的自签名证书，当您可以将自己的 CA 添加到客户端列表中时），无论是网络浏览器或其他任何东西。
使用自签名证书，用户如何知道该证书是您的还是攻击者的？他不能。
如果您完全控制进程的两端（服务器和客户端），您当然可以指示客户端始终信任“来自 Eugene 且指纹为 A01AABB546AC 的证书”，但是您需要构建自己的证书基础设施（到期/撤销）。
That's the entire point of trusted signing authorities - anything signed by someone else is supposed to give a security alert. So, no, there's no useful way to override this (unless you have control over the client computers - e.g. a self-signed certificate used for company-internal sites, when you can add your own CA into the clients' list), either for web browsers or anything else.
With a self-signed certificate, how can a user know whether the certificate is yours or an attacker's? He can't.
If you completely control both ends of the process (server and client), you can of course instruct the client to always trust "certificate from Eugene with a fingerprint of A01AABB546AC", for example, but then you need to build your own certificate infrastructure (expiration/revocation).
由于中间人的可能性，使用自签名证书不会增加理论上的安全性。此通信中的对方（您的客户端和您的服务器）不会有关于谁在说话或在听的附加信息，而这种加密的目的是确保通信中只有两个参与者，并且身份至少其中之一是已知的。
就您而言，密码不会安全地传输给您，因为您不知道它是否在途中通过了第三方。同样，用户也不知道他将密码发送给了谁。
在实践中，设置中间人攻击需要一些工作，也许这个障碍是某种安全性，但与强迫用户接受后果不明的安全警告的烦恼相比，确实“虚假安全感”的风险。
有些公司提供具有最低验证形式的免费证书（他们只会检查您是否“拥有”电子邮件地址 hostmaster@domain）。这样您也不必处理该警告。
除非有办法让你将证书或其指纹与应用程序打包在一起，正如 Piskvor 所说。
You will add no theoretical security by using a self-signed certificate, because of the possibility of man in the middle. The counterparts (your client and your server) in this communication will have no additional information about who is talking or listening, whereas the point of this kind of encryption is to make sure that there are only two participants in the communication and that the identity of at least one of them is known.
In your case, the password will not be transferred to you securely, because you don't know if it has passed through a third party on the way. Likewise, the user won't know who he sends the password to.
In practice, a man in the middle attack will be a bit of work to set up, and maybe that obstacle is some kind of security, but contrast that to the annoyance of forcing your users to accept a security warning with unclear consequences, and indeed the risk of "false sense of security".
There are companies that offer free certificates with the lowest form of validation (they will only check that you "own" the e-mail address hostmaster@domain). That way you won't have to do with the warning, either.
Unless there is a way for you to package your certificate or its fingerprint with the app, as Piskvor said.
感动地回答 - 对于这种类型的事情你应该没问题。用户唯一无法得到的是一种确认证书信任级别的方法（例如，您可以在浏览器中使用签名证书），但根据您对 @Piskvor 的评论，这听起来不像问题：你没有使用它。
Moved to answer - for this type of thing you should be fine. The only thing the users won't get is a way to confirm the trust level of the cert (like you could do with a signed cert in a browser for example) but as per your comment to @Piskvor that doesn't sound like an issue: you aren't using it for that.
回答你的问题：你可以，但你不应该！
首先，仅使用 SSL 进行身份验证根本不安全。身份验证过程可能会产生某种会话（例如cookie），然后在不加密的情况下传输该会话。因此，会话可能被盗（请参阅会话劫持）。
其次，使用自签名证书允许中间人攻击。因此，有人可以窃取用户的密码，而他可能甚至不会注意到。用户不知道客户端收到您的自签名证书时弹出的警报与使用攻击者自签名证书时显示的弹出警报之间的区别。
我的建议：不要使用自签名证书。当攻击发生时，这对您和您的客户都不利。
To answer your question: You can, but you shouldn't!
First, using SSL only for authentication isn't secure at all. The authentication process probably produces some kind of session (e.g. cookie) which is then transfered without encryption. Therefore, the session can be stolen (see Session hijacking).
Second, using a self-signed certificate allows man-in-the-middle attacks. So, someone can steal the user's password and he probably won't even notice it. The user doesn't know the difference between the alert that pops up when the client receives your self-signed certificat and the pop up that shows when the attackers self-signed certificate is used.
My advice: Don't use self-signed certificates. When an attack happens it's bad for you and your customers.
当您使用 SSL 连接使用密码加密登录对话时，服务器向客户端发送公钥（以证书的形式），客户端生成一次性会话密钥，并使用服务器的公钥对其进行加密，并将其发送到服务器。然后，服务器可以解密会话密钥，因为它拥有私钥。
然后，用户使用会话密钥加密其密码并将其发送到服务器，服务器可以解密它，因为它知道会话密钥。
现在，如果没有 PKI，如果攻击者想要了解您的密码，他可以欺骗服务器。他会向您发送他的公钥，您会以通常的方式生成会话密钥等，然后向他发送您的密码他可以解密该密码因为你会在不知道是否可以信任的情况下使用他的密钥。
PKI 通过要求将公钥作为证书分发来保护您免受此类攻击。如果您信任签署证书的 CA，您可以知道公钥确实属于服务器，并且使用它来加密您的密码是安全的。如果您不使用证书，或者使用不受信任的证书，您通常不知道要将密码发送给谁。
您没有提供有关您自己的特定用例的足够信息来确定您是否可以使用自签名证书...例如：您可能有一个由某个受信任渠道提前分发的固定证书并且您可以在开始 SSL 对话时检查是否使用了正确的证书。如果是这种情况，那么您的客户端已经知道它具有正确的公钥，并且不需要能够检查签名。但一般来说，您需要由受信任的 CA 签署的适当证书，否则您就没有安全性。
When you use an SSL connection to encrypt a login dialogue with a password the server sends the client a public key (in the form of a certificate), and the client generates a one-off session key, encrypts it using the server's public key, and sends it to the server. The server can then decrypt the session key because it has the private key.
The user then encrypts his password using the session key and sends that to the server, which can decrypt it because it knows the session key.
Now, without PKI if an attacker wanted to learn your password he could spoof the server. He'd send you his public key and you'd generate a session key, etc., in the usual way and send him your password which he would be able to decrypt because you'd be using his key without knowing whether you can trust it.
PKI protects you against this kind of attack by requiring that public keys are distributed as certificates. If you trust the CA that signed the certificate you can tell that the public key really does belong to the server and that it's safe to use it to encrypt your password. If you don't use a certificate -- or if you use an untrusted certificate -- you generally have no idea who you are sending your password to.
You don't give enough information about your own particular use case to say for certain whether you can use a self-signed certificate ... For example: It may be that you have one fixed certificate that is distributed in advance by some trusted channel and that you can check that the correct certificate is being used when you begin your SSL conversation. If that's the case then your client already knows that it has the correct public key and doesn't need to be able to check a signature. In general, though, you need a proper certificate signed by a trusted CA or else you have no security.