如何通过 SSL 实现 Web 服务到 Web 服务的通信？
How to achieve Web-service to Web-service communication over SSL?
2016 年 7 月 8 日更新。
我必须通过 SSL 实现 Web 服务到 Web 服务的通信。要求就像我们有一个在 Eclipse Virgo 服务器上运行的应用程序。该应用程序包含几个 OSGI 包。目前，当用户输入一些数据来存储应用程序时，应用程序会接受它并将数据保存到基于实体的异构数据源（数据库，使用 JNI 的 C 进程），这工作正常。
现在我需要实现的是，同一个应用程序将部署在多个服务器上，并且 UI 中会有一个选项来指定复制服务器（即具有相同应用程序的服务器 运行和需要复制的数据）。
为此，我们计划创建一个单独的包以拥有 Restful 网络服务，并移动所有持久性逻辑以将数据保存到异构数据源。此 Rest API 将检查可用的复制服务器，并且必须通过这些服务器中的 Rest 服务传递相同的数据。
需要注意的一点是，我们使用Spring安全框架来确保我们java应用程序的安全。由于我们不向任何第三方应用程序公开我们的网络服务，因此包括对网络服务的调用在内的所有调用都将使用它进行身份验证和授权。
我们这样做不是为了负载平衡。每台服务器都是独立的，我们使用安装程序安装应用程序以及所需的软件。这个想法是使用安装程序来创建和安装自签名证书。在安装应用程序时，我们可能不知道是否需要将其复制到另一台服务器。因为并非此应用程序的每个客户端都需要复制服务器。需要使用复制服务器的客户端必须能够在后期通过 Java Web 应用程序管理屏幕启用和禁用一个或多个复制服务器。从那里开始，一个服务器中发生的任何数据操作都需要以双向方式复制到其他服务器。
所以我的问题是我们如何动态获取 public 密钥并加密请求以双向方式连接到那些复制服务器，因为它在 SSL 中是 运行？
我对 SSL 的概念完全陌生。
提前致谢。
If you use certificates issued by a trusted CA you do not need additional configuration. But I guess you're going to use self-signed certificates because you have multiple servers and their use is not public
Each server requires its own SSL certificate bound to the IP or hostname of the server. I recommend creating a root certificate and an SSL certificate for each server certificate issued by the root. It is also possible to use a wildcard type * .domain.com.
You must include the root certificate in the trust store of the client application to achieve a successful SSL connection. To do so create a JKS keystore includes the root certificate and defines the trust store follows
System.setProperty ("javax.net.ssl.trustStore","path/to/your/truststore");
System.setProperty ("javax.net.ssl.trustStorePassword", "password");
You can modify the default truststore Also at jre/lib/security/cacerts
If you need detail of some step, please comment
EDITED
To create and distribute your certificate you can evaluate several options
1) Wildcard certificate *.domain.com
It allows multiple servers to share the domain with the same certificate. The certificate would be included in the installer, and the public part into the keystore of the client. A new replication server does not require additional configuration on the client. I think it is not applicable because you probably do not control the DNS of replication servers.
2) Self-signed certificate without a root CA
Each server generates its own self-signed certificate. Then the client must trust the certificate by including it in trustore.
Normally I would not recommend an automatic download process, because it involves connecting to an unsecure source (for now), to obtain the certificate X509 from ssl connection, open the truststore and add a new certificate, but since there is an operator to expressly perform the operation, I think it is feasible
Check the answer here showing how to create a custom TrustManager to rely on a host. After this open the truststore file in your server, add the certificate and save it (see Programmatically Import CA trust cert into existing keystore file without using keytool)
3) Self-signed certificate with a root CA
The certificate is created on client side, but is signed by your PKI (using a Public Key Infraestructure). The advantage is that your client only needs to include the root CA into the truststore. A new replication server is trusted whenever you use a certificate issued by this root CA.
For safety reason, you should not include the private key of your CA certificate in the installer. Then, the creation of the certificate will be more complex now. One option is previously create the certificate for the new hostname and send it along with the installer. Another option is to create a PKI infrastructure with a server responsible for signing the certificates
2016 年 7 月 8 日更新。
我必须通过 SSL 实现 Web 服务到 Web 服务的通信。要求就像我们有一个在 Eclipse Virgo 服务器上运行的应用程序。该应用程序包含几个 OSGI 包。目前，当用户输入一些数据来存储应用程序时，应用程序会接受它并将数据保存到基于实体的异构数据源（数据库，使用 JNI 的 C 进程），这工作正常。
现在我需要实现的是，同一个应用程序将部署在多个服务器上，并且 UI 中会有一个选项来指定复制服务器（即具有相同应用程序的服务器 运行和需要复制的数据）。
为此，我们计划创建一个单独的包以拥有 Restful 网络服务，并移动所有持久性逻辑以将数据保存到异构数据源。此 Rest API 将检查可用的复制服务器，并且必须通过这些服务器中的 Rest 服务传递相同的数据。
需要注意的一点是，我们使用Spring安全框架来确保我们java应用程序的安全。由于我们不向任何第三方应用程序公开我们的网络服务，因此包括对网络服务的调用在内的所有调用都将使用它进行身份验证和授权。
我们这样做不是为了负载平衡。每台服务器都是独立的，我们使用安装程序安装应用程序以及所需的软件。这个想法是使用安装程序来创建和安装自签名证书。在安装应用程序时，我们可能不知道是否需要将其复制到另一台服务器。因为并非此应用程序的每个客户端都需要复制服务器。需要使用复制服务器的客户端必须能够在后期通过 Java Web 应用程序管理屏幕启用和禁用一个或多个复制服务器。从那里开始，一个服务器中发生的任何数据操作都需要以双向方式复制到其他服务器。
所以我的问题是我们如何动态获取 public 密钥并加密请求以双向方式连接到那些复制服务器，因为它在 SSL 中是 运行？
我对 SSL 的概念完全陌生。
提前致谢。
If you use certificates issued by a trusted CA you do not need additional configuration. But I guess you're going to use self-signed certificates because you have multiple servers and their use is not public
Each server requires its own SSL certificate bound to the IP or hostname of the server. I recommend creating a root certificate and an SSL certificate for each server certificate issued by the root. It is also possible to use a wildcard type * .domain.com.
You must include the root certificate in the trust store of the client application to achieve a successful SSL connection. To do so create a JKS keystore includes the root certificate and defines the trust store follows
System.setProperty ("javax.net.ssl.trustStore","path/to/your/truststore");
System.setProperty ("javax.net.ssl.trustStorePassword", "password");
You can modify the default truststore Also at jre/lib/security/cacerts
If you need detail of some step, please comment
EDITED
To create and distribute your certificate you can evaluate several options
1) Wildcard certificate *.domain.com
It allows multiple servers to share the domain with the same certificate. The certificate would be included in the installer, and the public part into the keystore of the client. A new replication server does not require additional configuration on the client. I think it is not applicable because you probably do not control the DNS of replication servers.
2) Self-signed certificate without a root CA
Each server generates its own self-signed certificate. Then the client must trust the certificate by including it in trustore. Normally I would not recommend an automatic download process, because it involves connecting to an unsecure source (for now), to obtain the certificate X509 from ssl connection, open the truststore and add a new certificate, but since there is an operator to expressly perform the operation, I think it is feasible
Check the answer here
3) Self-signed certificate with a root CA
The certificate is created on client side, but is signed by your PKI (using a Public Key Infraestructure). The advantage is that your client only needs to include the root CA into the truststore. A new replication server is trusted whenever you use a certificate issued by this root CA.
For safety reason, you should not include the private key of your CA certificate in the installer. Then, the creation of the certificate will be more complex now. One option is previously create the certificate for the new hostname and send it along with the installer. Another option is to create a PKI infrastructure with a server responsible for signing the certificates