承德seo搜索推广_苏州做网版的公司_ip营销的概念_响应式网站模板的应用

Docker远程访问

问题：

生效不了的归根结底的原因就是

就是格式没弄好

这里的配置做了以下几点：

1. Docker守护进程启动：通过/usr/bin/dockerd命令启动Docker守护进程。

2. 监听配置

   • -H fd://：让Docker守护进程通过systemd提供的文件描述符监听Docker客户端请求。这是推荐的方式，因为它允许systemd管理Docker进程的生命周期，并且提高了安全性。
   • -H tcp://192.168.220.128:2375：让Docker守护进程监听TCP连接在指定的IP地址（192.168.220.128）和端口（2375）上。这种方式允许远程客户端连接到Docker守护进程，但出于安全考虑，通常不推荐在生产环境中使用，除非有适当的网络访问控制和加密措施。这里的ip就是你docker服务器的ip地址。

3. Containerd套接字路径：--containerd=/run/containerd/containerd.sock指定了Docker守护进程与containerd通信时使用的Unix套接字路径。containerd是Docker的一个组件，负责管理容器运行时。

请注意，直接在公开网络上暴露Docker守护进程（如通过TCP监听）可能会带来安全风险。在生产环境中，建议使用TLS加密Docker守护进程的通信，或者仅在受信任的内部网络上暴露Docker守护进程。此外，确保只有授权用户或服务能够访问Docker守护进程。

然后保存文件，执行下面命令重新加载systemctl配置。

 systemctl daemon-reload

重启Docker容器

 systemctl restart docker.service

通过查看 netstat 的输出以确认 dockerd 正在侦听配置的端口，以检查更改是否已生效。

 netstat -lntp | grep dockerd

如果docker有出错什么的，可以用下面语句看出错日志

systemctl status docker.service

后知后觉

发现，原来docker.d的override.conf是用来覆盖docker默认启动项的

建议做法：

我这里用的软件是finalshell

直接编写

systemctl edit --force docker.service

随便写个1先保存

然后

cd /
cd /etc/systemd/system/docker.service.d

然后，用下面文件打开去编辑，以免用命令行折磨
![!\

ip地址修改成功你自己服务器的ip地址，，云服务器（写0.0.0.0）

[Service]ExecStart=ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375 --containerd=/run/containerd/containerd.sock

然后保存文件，执行下面命令重新加载systemctl配置。

 systemctl daemon-reload

重启Docker容器

 systemctl restart docker.service

通过查看 netstat 的输出以确认 dockerd 正在侦听配置的端口，以检查更改是否已生效。

 netstat -lntp | grep dockerd

如果docker有出错什么的，可以用下面语句看出错日志

systemctl status docker.service

然后

开放防火墙端口 开放端口

sudo firewall-cmd --zone=public --add-port=2375/tcp --permanent

重新加载防火墙

firewall-cmd reload

云的记得去安全组里开放

安全认证

由于开放了端口没有做任何安全保护，会引起安全漏洞，被人入侵、挖矿、CPU飙升这些情况都有发生。 为解决这个问题：我们只要使用安全传输层协议（TLS）进行传输并使用CA认证即可

官网链接参考：保护 Docker 守护程序套接字 |Docker 文档

制作证书和秘钥

我们需要使用OpenSSL制作CA机构证书、服务端证书和客户端证书，以下操作均在安装Docker的
Linux服务器上进行。

首先创建一个目录用于存储生成的证书和秘钥

mkdir /home/docker-ca  
cd /home/docker-ca

我们将在这个文件夹下建立9个文件

服务端

ca.pem 根据私钥创建CA证书

server-key.pem 创建服务端私钥

server.csr 创建服务端证书签名请求文件，用于CA证书给服务端证书签名

server-cert.pem 创建CA证书签名好的服务端证书

客户端

key.pem 创建客户端私钥

client.csr 创建客户端证书签名请求文件，用于CA证书给客户证书签名

extfile-client.cnf 创建一个扩展配置文件

cert.pem 创建CA证书签名好的客户端证书

通过ls可以查看是否有这个东西

创建CA证书私钥，期间需要输入两次密码，生成文件为ca-key.pem

 openssl genrsa -aes256 -out ca-key.pem 4096

• openssl：这是调用 OpenSSL 命令行工具的命令。
• genrsa：这是 OpenSSL 中用于生成 RSA 私钥的命令。
• -aes256：这个选项指定使用 AES-256 加密算法对生成的私钥进行加密保护。这意味着在私钥被保存到文件之前，它会被加密，以后在使用这个私钥时，需要输入密码来解密。
• -out ca-key.pem：这个选项指定生成的私钥文件的名称和格式。-out 后面跟的是文件名，这里是 ca-key.pem。.pem 扩展名表示这是一个 PEM（Privacy Enhanced Mail）格式的文件，它是一种基于文本的编码格式，用于存储和发送加密材料。
• 4096：这个数字指定生成的 RSA 私钥的位数。4096 位是一个相对较大的密钥长度，提供了较高的安全性。较长的密钥更难被破解，但也会稍微增加加密和解密操作的计算成本。

密码自己设定，一般怎样好记怎样设定

根据私钥创建CA证书，期间需要输入上一步设置的私钥密码，生成文件为ca.pem

openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -subj "/CN=*" -out ca.pem

这个命令用于创建一个新的自签名 X.509 证书。下面是对命令中各个部分的详细分析：

1. openssl: 这是 OpenSSL 命令行工具的调用。OpenSSL 是一个强大的开源工具包，用于实现 SSL 和 TLS 协议以及提供加密功能。
2. req: 这个子命令用于处理证书签名请求（CSR 是 Certificate Signing Request 的缩写）。虽然 req 通常用于生成 CSR 并将其发送到 CA 以获取签名证书，但在这个命令中，它与 -new 和 -x509 选项结合使用来直接生成一个自签名证书。
3. -new: 这个选项指示 OpenSSL 生成一个新的证书签名请求。在这个上下文中，它与 -x509 一起使用，意味着我们将直接从 CSR 生成证书，而不是将其发送到外部 CA。
4. -x509: 这个选项告诉 OpenSSL 我们想要生成一个 X.509 证书而不是一个标准的 CSR。它与 -new 结合使用时，会生成一个自签名证书。
5. -days 365: 这个选项指定证书的有效期。在这个例子中，证书将被设置为有效期为 365 天（一年）。
6. -key ca-key.pem: 这个选项指定用于签名证书的私钥文件。在这个例子中，私钥存储在名为 ca-key.pem 的文件中。
7. -sha256: 这个选项指定用于签名证书的哈希算法。在这个例子中，使用的是 SHA-256 算法。
8. -subj "/CN=\*": 这个选项指定证书的主题字段。在这个例子中，只有一个字段被设置：通用名称（CN），并且其值被设置为一个星号（*）。然而，这是一个不正确的用法。CN 通常应该包含一个具体的名称，如域名或组织名。使用星号作为 CN 的值在 SSL/TLS 证书中是没有意义的，因为 CN 不支持通配符语法（通配符应该用在主题备用名称（SAN）字段中，并且需要由受信任的 CA 颁发才有效）。
9. -out ca.pem: 这个选项指定输出文件的名称。在这个例子中，生成的证书将被保存到名为 ca.pem 的文件中。

创建服务端私钥，生成文件为server-key.pem

openssl genrsa -out server-key.pem 4096

创建服务端证书签名请求文件，用于CA证书给服务端证书签名，生成文件 server.csr

 openssl req -subj "/CN=*" -sha256 -new -key server-key.pem -out server.csr

• openssl req: 这是 OpenSSL 中用于创建和处理证书签名请求的命令。

• -subj "/CN=*": 预填充 CSR 的主题字段。然而，"/CN=*" 不是一个有效的值；* 通常不会被接受为一个有效的 CN。

• -sha256: 指定使用 SHA-256 哈希算法。

• -new: 指示 OpenSSL 生成一个新的 CSR。

• -key server-key.pem: 指定包含私钥的文件。

• -out server.csr: 指定输出文件的名称，即生成的 CSR 文件。

指定 IP

6、指定 IP
允许指定的 ip 可以连接到服务器中的 docker，多个 ip 用逗号分隔，把下面的 2 个 127.0.0.1 改成服务器 IP 地址

echo subjectAltName = DNS:127.0.0.1,IP:127.0.0.1,IP:0.0.0.0 >> extfile.cnf

1
得到 extfile.cnf 文件

7、将 Docker 守护程序密钥的扩展使用属性设置为仅用于服务器身份验证

echo extendedKeyUsage = serverAuth >> extfile.cnf

创建CA证书签名好的服务端证书，期间需要输入CA证书私钥密码，生成文件为server-cert.pem

openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf

• openssl x509: 这是 OpenSSL 中用于处理 X.509 证书的命令。
• -req: 指示 OpenSSL 从一个 CSR 生成证书。
• -days 365: 设置证书的有效期为 365 天。
• -sha256: 使用 SHA-256 算法对证书进行签名。
• -in server.csr: 指定输入文件，即要签名的 CSR。
• -CA ca.pem: 指定 CA 证书文件。
• -CAkey ca-key.pem: 指定 CA 私钥文件。
• -CAcreateserial: 如果序列号文件不存在，则创建一个新的序列号文件。序列号文件通常用于跟踪由 CA 签发的证书。
• -out server-cert.pem: 指定输出文件的名称，即生成的证书文件。

创建客户端私钥，生成文件为key.pem

openssl genrsa -out key.pem 4096

• openssl：这是命令行工具的名称，用于执行 OpenSSL 相关的各种加密操作。
• genrsa：这是 OpenSSL 中的一个子命令，用于生成 RSA 私钥。
• -out key.pem：这个选项指定了输出文件的名称和格式。在这个例子中，私钥将被保存到名为 key.pem 的文件中，使用 PEM（Privacy Enhanced Mail）格式编码。
• 4096：这个数字指定了生成的 RSA 私钥的位大小。4096 位是一个相对较大的密钥大小，提供了较高的安全性。较大的密钥会增加加密和解密操作的计算成本，但也会使破解密钥变得更加困难。

创建客户端证书签名请求文件，用于CA证书给客户证书签名，生成文件client.csr

 openssl req -subj "/CN=client" -new -key key.pem -out client.csr

• openssl req：这是 OpenSSL 中用于处理证书签名请求的命令。
• -subj "/CN=client"：这个选项指定了 CSR 中的主题（subject）信息。在这个例子中，只设置了通用名称（CN，Common Name）为 “client”。主题信息通常包括证书所有者的标识信息，如组织名称、组织单位、国家/地区等。但在这个简单的例子中，只设置了 CN。
• -new：这个选项表示创建一个新的 CSR。
• -key key.pem：这个选项指定了用于生成 CSR 的私钥文件的路径。在这个例子中，它指向之前使用 openssl genrsa 命令生成的 key.pem 文件。
• -out client.csr：这个选项指定了输出文件的名称。在这个例子中，生成的 CSR 将被保存到名为 client.csr 的文件中。

为了让秘钥适合客户端认证，创建一个扩展配置文件extfile-client.cnf

 echo extendedKeyUsage = clientAuth > extfile-client.cnf

echo extendedKeyUsage = clientAuth > extfile-client.cnf 实际上是在创建一个名为 extfile-client.cnf 的新文件，并将 extendedKeyUsage = clientAuth 这行文本写入该文件。这个文件随后可以用作 OpenSSL 命令的一个输入，以指定在生成证书时应该包含的扩展密钥用途。

创建CA证书签名好的客户端证书，期间需要输入CA证书私钥密码，生成文件为 cert.pem

openssl x509 -req -days 365 -sha256 -in client.csr \
-CA ca.pem -CAkey ca-key.pem -CAcreateserial \
-out cert.pem -extfile extfile-client.cnf

• openssl x509：这是 OpenSSL 中用于处理 X.509 证书的命令。
• -req：表示输入文件是一个证书签名请求（CSR）。
• -days 365：设置证书的有效期为 365 天。
• -sha256：使用 SHA-256 哈希算法对证书进行签名。
• -in client.csr：指定输入的 CSR 文件。
• -CA ca.pem：指定 CA 的证书文件。
• -CAkey ca-key.pem：指定 CA 的私钥文件。
• -CAcreateserial：如果序列号文件不存在，则创建一个新的序列号文件。序列号文件通常用于跟踪由 CA 签发的证书。
• -out cert.pem：指定输出的证书文件。
• -extfile extfile-client.cnf：指定包含证书扩展的配置文件。

弄好用ls

会看到有十个文件

里面有一个文件ca.srl不是我创建的什么我很好奇，搜索了一下

ca.srl 文件通常与 SSL/TLS 证书颁发机构（CA）的序列号文件相关联。这个文件用于跟踪由特定 CA 签发的证书序列号。在 SSL/TLS 证书管理的过程中，每一个由 CA 签发的证书都会被分配一个唯一的序列号，以确保证书的唯一性。ca.srl 文件就是用来记录这些序列号的。

这个文件通常是在 CA 的私钥和证书创建时或之后生成的。当你使用 OpenSSL 或类似的工具来创建自签名证书或充当自己的 CA 来签发证书时，可能会遇到这个文件。下面是创建 ca.srl 文件的一些常见场景：

1. 创建 CA 密钥和证书：当你使用 OpenSSL 创建一个新的 CA 时，通常会生成一个 CA 的私钥和一个自签名证书。在这个过程中，如果指定了 -serial 选项并指向一个文件（如 ca.srl），则该文件会被用来记录序列号。如果未指定，OpenSSL 可能会在当前目录下创建一个默认的 .srl 文件来存储序列号。
2. 签发证书：当你使用 CA 来签发新的证书时，OpenSSL 会从 ca.srl 文件中读取当前的序列号，为新证书分配一个新的序列号，并更新该文件中的序列号。

删除创建过程中多余的文件

rm -rf ca.srl server.csr client.csr extfile-client.cnf extfile.cnf

最终生成文件如下，有了它们我们就可以进行基于TLS的安全访问了

ca.pem CA证书
ca-key.pem CA证书私钥
server-cert.pem 服务端证书
server-key.pem 服务端证书私钥
cert.pem 客户端证书
key.pem 客户端证书私钥

配置Docker支持TLS

先往下看，别急着敲

编辑docker服务启动文件

systemctl edit docker.service

在原来的基础上往后添加启动参数

[Service] 
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375 --containerd=/run/containerd/containerd.sock --tlsverify --tlscacert=/home/docker-ca/ca.pem --tlscert=/home/docker-ca/server-cert.pem --tlskey=/home/docker-ca/server-key.pem

• -H fd:// 告诉 Docker 守护进程监听 Unix 套接字文件（通常是 /var/run/docker.sock），这是 Docker 的默认行为，允许本地进程在不通过网络的情况下与 Docker 守护进程通信。
• -H tcp://0.0.0.0:2375 配置 Docker 守护进程在 TCP 端口 2375 上监听所有网络接口。请注意，这样做会使 Docker 守护进程暴露在不安全的网络上，除非使用了 TLS（如您所做的那样）。
• --tlsverify 启用 TLS 验证，要求客户端提供有效的 TLS 证书才能与 Docker 守护进程通信。
• --tlscacert、--tlscert 和 --tlskey 分别指定 CA 证书、服务器证书和服务器私钥的路径。

请确保：

• /home/docker-ca/ca.pem、/home/docker-ca/server-cert.pem 和 /home/docker-ca/server-key.pem 文件的路径是正确的，并且这些文件对运行 Docker 服务的用户是可读的。
• Docker 守护进程有权访问指定的 --containerd 套接字。
• 如果将 Docker 守护进程配置为监听 TCP 端口，并且启用了 TLS，那么任何尝试连接到该端口的客户端都必须提供有效的 TLS 证书。这包括 Docker 客户端、Docker Compose、Kubernetes 节点等。

我的建议是这样改比较不折磨，用命令界面去改好折磨人的

然后保存文件，执行下面命令重新加载systemctl配置。

systemctl daemon-reload
重启Docker容器systemctl restart docker检查systemctl status docker

客户端访问

下载证书到本地磁盘，主要下载下面三个文件
ca.pem CA证书
cert.pem 客户端证书
key.pem 客户端证书私钥

比如我下载到我的本地电脑的
E:\Workspace\docker-ca
这个位置。
记住这个位置，后面打包部署的时候需要指定该目录的，具体使用我们在打包部署的时候会用到。

这个软件是FinalShell

![image-20250309172633047](C:\Users\LX\AppData\Roaming\Typora\typora-user-images\image-20250309172633047.png

检查防火墙

systemctl status firewalld.service

关闭防火墙（暂时的关闭）

systemctl stop firewalld.service

再次检查

然后去idea配置

如果一直遇到一些问题可以参考一下这篇文章

文章链接

附上docker进程相关命令

启动Docker命令
systemctl start docker# 
停止Docker命令
systemctl stop docker# 
重启Docker命令
systemctl restart docker# 
查看启动结果
systemctl status docker# 
设置开机启动Dockersystemctl enable docker

名词解释：签发终端实体证书

签发终端实体证书是PKI（公钥基础设施）体系中的一个关键环节，指由证书颁发机构（CA）向最终用户或设备发放用于身份认证和加密通信的数字证书。以下是具体解析：

1. 终端实体的定义
   终端实体（End Entity，EE）是PKI体系中的最终服务使用者，可以是个人、组织、设备（如服务器、路由器）或应用程序25。其核心特征是不具备签发其他证书的权限，仅用于证明自身身份或加密通信25。例如：

服务端证书：部署在Web服务器上，用于HTTPS加密；
客户端证书：安装在用户终端（如浏览器），用于双向认证；
设备证书：嵌入IoT设备，确保设备合法性。
2. 签发终端实体证书的流程
签发过程通常由**子CA（从属CA）**完成，而非根CA26：

层级结构：根CA作为信任链的起点，签发子CA证书；子CA进一步向终端实体颁发证书25。
扩展文件（extfile）的作用：在OpenSSL中，-extfile参数通过配置文件（如ext.conf）定义证书的扩展属性，例如：
SAN（Subject Alternative Name）：允许一个证书绑定多个域名或IP地址6；
密钥用途：明确证书用途（如加密、签名）4。
这些扩展信息通过openssl x509命令在签发终端实体证书时生效1。
3. 终端实体证书的特点
不可签发其他证书：与CA证书不同，终端实体证书的密钥仅用于加密通信或身份验证，不能用于签发下级证书5。
信任链验证：客户端通过证书链追溯到根CA，验证终端实体证书的合法性23。例如，浏览器检查服务器证书是否由可信CA签发。
应用场景：TLS/SSL加密（如HTTPS）、电子邮件签名（S/MIME）、VPN设备认证等36。
4. 与CA证书的区别
特性 终端实体证书 CA证书
用途 加密通信、身份验证 签发其他证书
签发者 子CA或根CA 根CA（自签名）或上级CA
扩展属性 包含SAN、密钥用途等应用层扩展 包含CA:TRUE标记，允许签发证书5
信任链终点 是信任链的末端 是信任链的中间节点或根节点2
5. 实际案例
以阿里云私有证书为例：

用户需先创建子CA，通过子CA签发终端实体证书（服务端/客户端证书）6；
扩展文件（如SAN）在申请证书时通过配置文件添加，确保证书支持多域名绑定6。
综上，“签发终端实体”指通过CA体系为终端用户或设备颁发仅用于身份验证或加密的证书，其核心在于通过层级化的信任链和扩展属性满足实际应用场景需求。