可以考虑下gRPC提供的从客户端到服务器的整套解决方案,gRPC 调用是通过 HTTP POST

图片 8

摘要NGINX 官方博客正式宣布 NGINX 支持原生的
gPRC,现在就可以从代码仓库拉取快照版本。该特性将会被包含在 NGINX OSS
1.13.10、NGINX Plus R15 以及 NGINX 1.13.9 当中。引言NGINX
官方博客正式宣布 NGINX 支持原生的
gPRC,现在就可以从代码仓库拉取快照版本。该特性将会被包含在 NGINX OSS
1.13.10、NGINX Plus R15 以及 NGINX 1.13.9
当中(博客原文链接:
已经能够代理 gRPC TCP 连接,用户可以用它:发布 gRPC 服务,并应用 NGINX
提供的 HTTP/2 TLS 加密机制、速率限定、基于 IP
的访问控制以及日志等功能。在单个端点上发布多个 gRPC 服务,使用 NGINX
检查方法调用,将各个方法调用路由到相应的服务上。对一组 gRPC
服务进行负载均衡,可以使用轮询算法、最少连接数原则或其他方式在集群上分发流量。什么是
gRPC?gRPC
是一种远程过程调用协议(gRPC官网:
3.x,基于Netty 4.x +,用于客户端和服务器端之间的通信。gRPC
紧凑小巧,跨多种编程语言,同时支持请求与响应式的交互方式和流式交互方式。gRPC
因其跨语言特性和简洁的设计变得越来越流行,其中服务网格的实现就使用了
gRPC。gRPC 通过 HTTP/2 传输数据,可以传输明文文本数据和 TLS
加密过的数据。gRPC 调用是通过 HTTP POST
请求来实现的,每个请求里包含了一个编码过的消息体(protocol buffer
是默认的编码方式)。gRPC
的响应消息里也包含一个编码过的消息体,并在消息尾部带上状态码。gRPC
不能通过 HTTP 进行传输,而必须使用 HTTP/2,这是因为要充分利用 HTTP/2
连接的多路复用和流式特性。通过 NGINX 来管理 gRPC 服务下面的示例对 gRPC
的 Hello World
快速入门教程进行了修改,用它来创建一个简单的客户端到服务器端应用。例子中提供了
NGINX
的配置信息,而把应用程序的实现留给读者,不过文中还是会给出一些提示。1、暴露简单的
gRPC 服务首先,在客户端和服务器端之间安插 NGINX,NGINX
为服务器端的应用程序提供了一个稳定可靠的网关。然后开始部署包含了 gRPC
更新包的 NGINX。如果要从源代码开始编译 NGINX,要记得把 http_ssl 和
http_v2 两个模块包含进去:$ auto/configure –with-http_ssl_module
—with-http_v2_moduleNGINX 使用一个 HTTP 服务器来监听 gRPC 流量,并使用
grpc_pass 指令来代理 gRPC 流量。像下面的配置那样,在 80
端口上监听未加密的 gRPC 流量,并把请求重定向到 50051 端口上:http {
log_format main ‘$remote_addr – $remote_user [$time_local]
“$request” ‘ ‘$status $body_bytes_sent “$http_referer” ‘
‘”$http_user_agent”‘; server { listen 80 http2; access_log
logs/access.log main; location / { # Replace localhost:50051 with the
address and port of your gRPC server # The ‘grpc://’ prefix is
optional; unencrypted gRPC is the default grpc_pass
grpc://localhost:50051; } }}要确保 grpc_pass
的地址是正确的。然后重新编译客户端,让它指向 NGINX 的 IP
地址和端口。在运行新的客户端时,可以看到与之前一样的响应消息,不过这时
NGINX 会终断和转发事务。这个可以从访问日志中看出来:$ tail
logs/access.log192.168.20.1 – – [01/Mar/2018:13:35:02 +0000] “POST
/helloworld.Greeter/SayHello HTTP/2.0” 200 18 “-”
“grpc-go/1.11.0-dev”192.168.20.1 – – [01/Mar/2018:13:35:02 +0000]
“POST /helloworld.Greeter/SayHelloAgain HTTP/2.0” 200 24 “-”
“grpc-go/1.11.0-dev”要注意,NGINX 不支持在同一个明文(非
TLS)端口上同时使用 HTTP/1 和
HTTP/2,如果一定要同时使用两种版本的协议,需要分别为它们创建不同的端口。2、发布基于
TLS 的 gRPC 服务Hello World 快速入门教程使用的是未加密的
HTTP/2,这样方便测试和部署,但要部署到生产环境就不能这么简单了。可以通过
NGINX 来增加一个加密层:创建一个自签名的证书对,然后修改 NGINX
服务器的配置如下:server { listen 1443 ssl http2; ssl_certificate
ssl/cert.pem; ssl_certificate_key ssl/key.pem; #…}让 gRPC
客户端使用 TLS,连接到 1443
端口,并禁用证书检查——这在使用自签名证书或未经信任的证书时是一个必要的步骤。例如,如果使用了
Go 语言编写的示例,就需要导入 crypto/tls 和
google.golang.org/grpc/credentials,并修改 grpc.Dial() 方法:creds :=
credentials.NewTLS( &tls.Config{ InsecureSkipVerify: true } )//
记得修改地址,使用新的端口conn, err := grpc.Dial( address,
grpc.WithTransportCredentials( creds ) )这样就可以加密 gRPC
流量了。在部署到生产环境时,需要将自签名证书换成由可信任证书机构发布的证书,客户端也需要配置成信任该证书。3、代理加密的
gRPC 服务有时候可能需要在内部对 gRPC
流量进行加密,那么就要修改服务器端应用程序的配置,把原先监听未加密(grpc)连接改为监听
TLS 加密(grpcs)连接。cer, err := tls.LoadX509KeyPair( “cert.pem”,
“key.pem” )config := &tls.Config{ Certificates: []tls.Certificate{cer}
}lis, err := tls.Listen( “tcp”, port, config )在 NGINX 的配置里,需要将
grpc-pass 配置成上游服务器的地址:# Use grpcs for TLS-encrypted gRPC
trafficgrpc_pass grpcs://localhost:50051;4、路由 gRPC
流量如果同时存在多个 gRPC
服务,并且每个服务是由不同的服务器应用程序提供的,那么该怎么办?如果能够将这些服务通过单个
TLS 端点暴露出来是不是更好?在 NGINX
里,可以对服务和它的方法稍作修改,然后使用 location 指令来路由流量。gRPC
的请求 URL 是使用包名、服务名和方法名来生成的。比如这个叫作 SayHello 的
RPC 方法:package helloworld;service Greeter { rpc SayHello
(HelloRequest) returns (HelloReply) {}}调用这个方法就会生成一个 POST
请求,URL 是
/helloworld.Greeter/SayHello,这个可以从日志中看出来:192.168.20.1 – –
[01/Mar/2018:13:35:02 +0000] “POST /helloworld.Greeter/SayHello
HTTP/2.0” 200 18 “-” “grpc-go/1.11.0-dev”要使用 NGINX
来路由流量,可以这样配置:location /helloworld.Greeter { grpc_pass
grpc://192.168.20.11:50051;}location /helloworld.Dispatcher { grpc_pass
grpc://192.168.20.21:50052;}location / { root html; index index.html
index.htm;}6、对 gRPC 流量进行负载均衡那么该如何增加 gRPC
服务的容量,以便提供高可用性?可以使用 NGINX 的 upstream 组:upstream
grpcservers { server 192.168.20.21:50051; server
192.168.20.22:50052;}server { listen 1443 ssl http2; ssl_certificate
ssl/certificate.pem; ssl_certificate_key ssl/key.pem; location
/helloworld.Greeter { grpc_pass grpc://grpcservers; error_page 502 =
/error502grpc; } location = /error502grpc { internal; default_type
application/grpc; add_header grpc-status 14; add_header grpc-message
“unavailable”; return 204; }}当然,如果上游监听的是 TLS 端口,可以使用
grpc_pass grpcs://upstreams。NGINX
支持多种负载均衡算法,其内置的健康检测机制可以检测到无法及时响应或发生错误的服务器,并把它们移除。如果没有可用的服务器,就会返回
/error502grpc 指定的错误消息。

7. gRPC使用自建证书

将server.cer(证书)和server.key(私钥)拷贝到工作目录

图片 1

 

gRPC的通信组件是netty、okhttp,netty带了ssl实现,有动态和静态两种方式来提供TLS的实现库,为了开发方便,我这里使用了boringssl实现库。okhttp也实现了TLS,但okhttp使用在移动端,故在此不表。

<dependency>

    <groupId>io.grpc</groupId>
    <artifactId>grpc-all</artifactId>
    <version>${grpc.version}</version>
</dependency>
<dependency>
    <groupId>io.netty</groupId>
    <artifactId>netty-tcnative-boringssl-static</artifactId>
    <version>1.1.33.Fork23</version>
</dependency>

 

gRPC Server端

使用TLS,添加证书和私钥

/* The port on which the server should run */
int port = 8443;
server = ServerBuilder.forPort(port)
    .addService(new GreeterImpl())
    .useTransportSecurity(loadCert("server.cer"),loadCert("server.key"))
    .build()
    .start();
logger.info("Server started, listening on " + port);
Runtime.getRuntime().addShutdownHook(new Thread() {
  @Override
  public void run() {
    // Use stderr here since the logger may have been reset by its JVM shutdown hook.
    System.err.println("*** shutting down gRPC server since JVM is shutting down");
    HelloWorldServer.this.stop();
    System.err.println("*** server shut down");
  }
});

 

 

gRPC Client端

添加信任的证书,同时注意刚才我们建立证书的时候,域名是wancai,所以在这里需要添加域名,否则链接失败。

SslContext sslContext = null;
try {
  sslContext = GrpcSslContexts.forClient().trustManager(
          loadCert("server.cer")).build();
} catch (Exception ex) {
  throw new RuntimeException(ex);
}
InetAddress address;
try {
  address = InetAddress.getByName(host);
  address = InetAddress.getByAddress("wancai", address.getAddress());
} catch (UnknownHostException ex) {
  throw new RuntimeException(ex);
}
channel = NettyChannelBuilder.forAddress(new InetSocketAddress(address, port))
        .flowControlWindow(65 * 1024)
        .negotiationType(NegotiationType.TLS)
        .sslContext(sslContext)
        .build();
blockingStub = GreeterGrpc.newBlockingStub(channel);

 

最后,我们通过 wireshark,抓包看看使用TLS加密和不加密通信的信息。

图片 2

当没有加密时,通信如下

图片 3

 

参考资料

 

图片 4

3.2 服务器端程序

然后编辑服务器端程序:

package main

import (
    "log"
    "net"

    pb "your_path_to_gen_pb_dir/helloworld"
    "golang.org/x/net/context"
    "google.golang.org/grpc"
)

const (
    port = ":50051"
)

// server is used to implement helloworld.GreeterServer.
type server struct{}

// SayHello implements helloworld.GreeterServer
func (s *server) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {
    return &pb.HelloReply{Message: "Hello " + in.Name}, nil
}

func main() {
    lis, err := net.Listen("tcp", port)
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }
    s := grpc.NewServer()
    pb.RegisterGreeterServer(s, &server{})
    s.Serve(lis)
}

这里首先定义一个server结构,然后实现SayHello的接口,其定义在“your_path_to_gen_pb_dir/helloworld”

SayHello(context.Context, *HelloRequest) (*HelloReply, error)

然后调用grpc.NewServer() 创建一个server s。接着注册这个server
s到结构server上面 pb.RegisterGreeterServer(s, &server{})
最后将创建的net.Listener传给s.Serve()。就可以开始监听并服务了,类似HTTP的ListenAndServe。

此时,可以使用以下apt命令安装certbot:

3. HTTP/2

HTTP/2,主要是基于Google的SPDY协议,是自HTTP/1.1从1999年发布16年后的首次更新。Servlet4.0将完全支持HTTP/2。

3. 示例程序

小结:

引子

gRPC是由Google主导开发的RPC框架,使用HTTP/2协议并用ProtoBuf作为序列化工具。其客户端提供Objective-C、Java接口,服务器侧则有Java、Golang、C++等接口,从而为移动端(iOS/Androi)到服务器端通讯提供了一种解决方案。
当然在当下的环境下,这种解决方案更热门的方式是RESTFull
API接口。该方式需要自己去选择编码方式、服务器架构、自己搭建框架(JSON-RPC)。gRPC官方对REST的声音是:

有各种Certbot插件用于获取SSL证书。
这些插件有助于获取证书,而其安装和Web服务器配置都留给管理员。
我们将使用一个名为Webroot的插件获取SSL证书。

在gRPC里,如果仅仅是用来做后端微服务,可以考虑不加密。本文太长,先给个大纲。

3.3 客户端程序

客户端程序:

package main

import (
    "log"
    "os"

    pb "your_path_to_gen_pb_dir/helloworld"
    "golang.org/x/net/context"
    "google.golang.org/grpc"
)

const (
    address     = "localhost:50051"
    defaultName = "world"
)

func main() {
    // Set up a connection to the server.
    conn, err := grpc.Dial(address, grpc.WithInsecure())
    if err != nil {
        log.Fatalf("did not connect: %v", err)
    }
    defer conn.Close()
    c := pb.NewGreeterClient(conn)

    // Contact the server and print out its response.
    name := defaultName
    if len(os.Args) > 1 {
        name = os.Args[1]
    }
    r, err := c.SayHello(context.Background(), &pb.HelloRequest{Name: name})
    if err != nil {
        log.Fatalf("could not greet: %v", err)
    }
    log.Printf("Greeting: %s", r.Message)
}

这里通过pb.NewGreeterClient()传入一个conn创建一个client,然后直接调用client上面对应的服务器的接口

SayHello(context.Context, *HelloRequest) (*HelloReply, error)

接口,返回*HelloReply 对象。

先运行服务器,在运行客户端,可以看到。

./greeter_server &

./greeter_client
2016/03/10 21:42:19 Greeting: Hello world

该文件的内容将是指定证书和密钥位置的指令。粘贴以下内容:

  1. HTTPS,HTTP/2介绍

  2. TLS加密原理、实现库

  3. HTTP/2协议协商机制

  4. 自建数字证书(CA)

  5. gRPC使用TLS

至于是否要选择用gRPC。对于已经有一套方案的团队,可以参考下。如果是从头来做,可以考虑下gRPC提供的从客户端到服务器的整套解决方案,这样不用客户端去实现http的请求会话,JSON等的解析,服务器端也有现成的框架用。从15年3月到现在gRPC也发展了一年了,慢慢趋于成熟。下面我们就以gRPC的Golang版本看下其在golang上面的表现。至于服务端的RPC,感觉golang标准库的RPC框架基本够用了,没必要再去用另一套方案。

#$ EDITOR/etc/nginx/sites-available/default

数字签名

数字签名就如同日常生活中的签名一样,这是任何人都没法仿造的。在计算机中的数字签名就是用于验证传输的内容是不是真实服务器发送的数据,发送的数据有没有被篡改过。

 

  • 和REST一样遵循HTTP协议(明确的说是HTTP/2),但是gRPC提供了全双工流
  • 和传统的REST不同的是gRPC使用了静态路径,从而提高性能
  • 用一些格式化的错误码代替了HTTP的状态码更好的标示错误

在NGINX上配置SSL/TLS

 

2. 安装gRPC-go

gRPC-go可以通过golang 的get命令直接安装,非常方便。

go get google.golang.org/grpc

这里大家可能比较奇怪,为什么gRPC-go在github的地址是”https://github.com/grpc/grpc-go”,但是为什么要用“google.golang.org/grpc”进行安装呢?应该grpc原本是google内部的项目,归属golang,就放在了google.golang.org下面了,后来对外开放,又将其迁移到github上面了,又因为golang比较坑爹的import路径规则,所以就都没有改路径名了。

但是这样就有个问题了。要如何去管理版本呢?这个目前我还没有什么比较好的方法,希望知道的朋友一起分享下。目前想到一个方法是手动下载某个版本,然后写个脚本统一修改代码中的import里面的路径.

在此过程中,Cerbot将要求有效的电子邮件地址进行通知。它也会要求与EFF分享,但这不是必需的。在同意服务条款之后,它将获得一个新的证书。

2.1 HTTPS的作用(来自百度)

  • 认证用户和服务器,确保数据发送到正确的客户机和服务器;(验证证书)

  • 加密数据以防止数据中途被窃取;(加密)

  • 维护数据的完整性,确保数据在传输过程中不被改变。(摘要算法)

 

HTTPS之所以安全,就是HTTP建立在SSL/TLS之上的。

图片 5

(网图)

 

SSL/TLS协议的基本思路是采用公钥加密法,也就是说,客户端先向服务器端索要公钥,然后用公钥加密信息,服务器收到密文后,用自己的私钥解密。

 

(1)如何保证公钥不被篡改?

将公钥放在数字证书中。只要证书是可信的,公钥就是可信的。

 

(2)公钥加密计算量太大,如何减少耗用的时间?

每一次对话,客户端和服务器端都生成一个”对话密钥”,用它来加密信息。由于”对话密钥”是对称加密,所以运算速度非常快,而服务器公钥只用于加密”对话密钥”本身,这样就减少了加密运算的消耗时间。

 

也就是说,对于HTTPS,由于成本问题

  • 握手阶段(handshake)用的非对称加密

  • 数据通信用的是对称加密

 

3.1 protobuf

该示例源自gRPC-go的examples的helloworld。先看PB的描述:

syntax = "proto3";

option objc_class_prefix = "HLW";

package helloworld;

// The greeting service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

这里定义了一个服务Greeter,其中有个API
SayHello。其接受参数为HelloRequest类型,返回HelloReply类型。这里HelloRequestHelloReply就是普通的PB定义

服务定义为:

// The greeting service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

service定义了一个server。其中的接口可以是四种类型

  • rpc GetFeature(Point) returns (Feature) {}
    类似普通的函数调用,客户端发送请求Point到服务器,服务器返回相应Feature.
  • rpc ListFeatures(Rectangle) returns (stream Feature) {}
    客户端发起一次请求,服务器端返回一个流式数据,比如一个数组中的逐个元素
  • rpc RecordRoute(stream Point) returns (RouteSummary) {}
    客户端发起的请求是一个流式的数据,比如数组中的逐个元素,服务器返回一个相应
  • rpc RouteChat(stream RouteNote) returns (stream RouteNote) {}
    客户端发起的请求是一个流式数据,比如数组中的逐个元素,二服务器返回的也是一个类似的数据结构

后面三种可以参考官方的route_guide示例。

使用protoc命令生成相关文件:

protoc --go_out=plugins=grpc:. helloworld.proto
ls
helloworld.pb.go    helloworld.proto

生成对应的pb.go文件。这里用了plugins选项,提供对grpc的支持,否则不会生成Service的接口。

# certbot certonly –webroot –webroot-path=/var/www/html -d
www.example.com

前几天看到微信后台团队分享了TLS相关文章,正好gRPC里TLS数据加密是很重要的一块,于是整理出了这篇文章。

1. 安装protobuf

虽然gRPC也支持protobuf2.x,但是建议还是使用protobuf3.x,尽管还没有正式版本,不过golang版本基本没有什么问题,另外3.x官方支持了Objective-C,这也是我们使用gRPC的初衷:提供一个移动端到服务器的解决方案。去到Protocol
Buffers下载最新版本(Version3.0.0
beta2),然后解压到本地。本地需要已经安装好autoconf automake libtool.rpm系列(fedora/centos/redheat)可以用yum安装。Mac上可以用brew进行安装

brew install autoconf automake libtool

然后执行

./configure --prefix=your_pb_install_path

接着

make 
make install
set your_pb_install_path to your $PATH

检查是否安装完成

protoc --version
libprotoc 3.0.0

然后安装golang protobuf直接使用golang的get即可

go get -u github.com/golang/protobuf/proto // golang protobuf 库
go get -u github.com/golang/protobuf/protoc-gen-go //protoc --go_out 工具

#add-apt-repository ppa:certbot / certbot

3.2 HTTP/2主要特性:

  • request/response多路复用(multiplexing)

  • 二进制帧传输(binary framing)

  • 数据流优先级(stream prioritization)

  • 服务器推送(server push)

  • 头信息压缩(header compression)

 

HTTP/2是站在HTTP/1.1肩膀上的一个改进而已,跟HTTP/1.1相比:

  • 相同的request/response模式

  • 没有新的method

  • 没有新的header

  • 在应用层没有引入新的花样

  • 没有修改URL规范、没有修改其他底层规范

 

HTTP/2仅是一个协议而已,它可以建立在TLS之上,也可以不。但是,根据

配置NGINX

4.1 实现库

TLS协议的设计目标是构建一个安全传输层(Transport Layer Security
),在基于连接的传输层(如tcp)之上提供。

 

TLS是用来做加密数据传输的,因此它的主体当然是一个对称加密传输组件。为了给这个组件生成双方共享的密钥,因此就需要先搞一个认证密钥协商组件,TLS协议自然分为:

  1. 做对称加密传输的record协议 ,the record protocol

  2. 做认证密钥协商的handshake协议,the handshake protocol

还有3个很简单的辅助协议:

  1. changecipher spec 协议,the changecipher spec protocol,
    用来通知对端从handshake切换到record协议(有点冗余,在TLS1.3里面已经被删掉了)

  2. alert协议,the alert protocol, 用来通知各种返回码,

  3. application data协议, The application data
    protocol,就是把http,smtp等的数据流传入record层做处理并传输。

图片 6

(网图)

 

如上看到,要实现TLS协议是很复杂的,目前他的实现也已经有很多了,当然最著名的当属
openssl
在wikipedia里已经列的很详细了。gRPC里由于是基于netty的,netty里的TLS实现库主要是BoringSSL、OpenSSL

大家可以参考

 

#$ EDITOR/etc/nginx/sites-available/default

5.2 编码格式

同样的X.509证书,可能有不同的编码格式

  • PEM – Privacy Enhanced Mail,打开看文本格式,以”—–BEGIN…”开头,
    “—–END…”结尾,内容是BASE64编码.
    查看PEM格式证书的信息:openssl x509 -in certificate.pem -text
    -noout
    Apache和*NIX服务器偏向于使用这种编码格式.

  • DER – Distinguished Encoding Rules,打开看是二进制格式,不可读.
    查看DER格式证书的信息:openssl x509 -in certificate.der -inform
    der -text -noout
    Java和Windows服务器偏向于使用这种编码格式.

5.3 相关的文件扩展名

虽然我们已经知道有PEM和DER这两种编码格式,但文件扩展名并不一定就叫”PEM”或者”DER”,常见的扩展名除了PEM和DER还有以下这些,它们除了编码格式可能不同之外,内容也有差别,但大多数都能相互转换编码格式.

  • CRT –
    CRT应该是certificate的三个字母,其实还是证书的意思,常见于*NIX系统,有可能是PEM编码,也有可能是DER编码,大多数应该是PEM编码,相信你已经知道怎么辨别.

  • CER –
    还是certificate,还是证书,常见于Windows系统,同样的,可能是PEM编码,也可能是DER编码,大多数应该是DER编码.

  • KEY –
    通常用来存放一个公钥或者私钥,并非X.509证书,编码同样的,可能是PEM,也可能是DER.
    查看KEY的办法:openssl rsa -in mykey.key -text -noout
    如果是DER格式的话,同理应该这样了:openssl rsa -in mykey.key -text
    -noout -inform der

  • CSR – Certificate Signing
    Request,即证书签名请求,这个并不是证书,而是向权威证书颁发机构获得签名证书的申请,其核心内容是一个公钥(当然还附带了一些别的信息),在生成这个申请的时候,同时也会生成一个私钥,私钥要自己保管好。
    查看的办法:openssl req -noout -text -in my.csr

  • PFX/P12 – predecessor of
    PKCS#12,对*nix服务器来说,一般CRT和KEY是分开存放在不同文件中的,但Windows的IIS则将它们存在一个PFX文件中,(因此这个文件包含了证书及私钥),PFX通常会有一个”提取密码”,你想把里面的东西读取出来的话,它就要求你提供提取密码,PFX使用的时DER编码,如何把PFX转换为PEM编码?
    openssl pkcs12 -in for-iis.pfx -out for-iis.pem -nodes
    这个时候会提示你输入提取代码. for-iis.pem就是可读的文本.
    生成pfx的命令类似这样:openssl pkcs12 -export -in
    certificate.crt -inkey privateKey.key -out
    certificate.pfx -certfile
    CACert.crt其中CACert.crt是CA(权威证书颁发机构)的根证书,有的话也通过-certfile参数一起带进去.这么看来,PFX其实是个证书密钥库.

  • JKS – 即Java Key
    Storage,这是Java的专利,跟OpenSSL关系不大,利用Java的一个叫”keytool”的工具,可以将PFX转为JKS

5.4 证书编码的转换

  • PEM转为DER openssl x509 -in cert.crt -outform der -out cert.der

  • DER转为PEM openssl x509 -in cert.crt -inform der -outform pem -out
    cert.pem

 

这将启用NGINX上的加密。
保存,退出并检查NGINX配置文件:

1. HTTP/1.x

目前绝大多数网站和APP都是建立在HTTP之上的,所有的数据都是明文传输,没有任何安全可言。

图片 7

网图 

ssl_certificate/etc/letsencrypt/live/domain_name/fullchain.pem;
ssl_certificate_key/etc/letsencrypt/live/domain_name/privkey.pem;

3.1 HTTP/1.1的问题

  • 假设一个网站需要加载几十个资源(css、js、jpg、等等),等到html文件加载成功后,浏览器会一个一个请求这些资源,并等待服务器按顺序一个一个返回。

  • 一个请求,一个应答

  • http header

如果没有错误,应该显示:

非对称密钥

服务端会生成一对密钥,一个私钥保存在服务端,仅自己知道,另一个是公钥,公钥可以自由发布供任何人使用。客户端的明文通过公钥加密后的密文需要用私钥解密。非对称密钥在加密和解密的过程的使用的密钥是不同的密钥,加密和解密是不对称的,所以称之为非对称加密。与对称密钥加密相比,非对称加密无需在客户端和服务端之间共享密钥,只要私钥不发给任何用户,即使公钥在网上被截获,也无法被解密,仅有被窃取的公钥是没有任何用处的。常见的非对称加密有RSA。

 

Let’s Encrypt 是什么?

6.2 签发自建证书

a) 生成证书私钥

$ openssl genrsa -aes256 -out server.pem 2048 (生成私钥)

$ openssl pkcs8 -topk8 -in server.pem -out server.key -nocrypt

 

b)生成证书签发申请文件

$openssl req -new -key server.key -out server.csr -subj
“/C=CN/ST=myprovince/L=mycity/O=myorganization/OU=mygroup/CN=wancai”

 

c)使用根证书签发服务端证书

$ openssl x509 -req -days 365 -sha1 -extensions v3_req -CA ca.cer
-CAkey ca.key -CAserial ca.srl -CAcreateserial -in server.csr -out
server.cer

图片 8

 

重新启动NGINX:

相关文章

Leave a Comment.