Posts

Title: Using ssl_password_file in NGINX for SSL/TLS Private Key Management Introduction The ssl_password_file directive in NGINX specifies a file containing passwords used to unlock encrypted SSL/TLS private keys. When NGINX starts or reloads, it reads this file to load and decrypt the private key. Incorrect passwords in this file will prevent NGINX from starting or reloading successfully. Syntax Syntax: ssl_password_file file; Default: — Context: http, server This directive appeared in version 1.7.3. file: Specifies the path to the password file. Each line in the file should contain a single password. When loading a private key, NGINX will try the passwords in sequence. Default By default, the ssl_password_file directive is not enabled, and no password file is set. ...

ssl_password_file 是 NGINX 中的一个指令，用于指定一个包含密码的文件，这个文件用于提供 SSL/TLS 私钥的密码。该指令在 NGINX 启动时会读取该文件，并用于加载私钥文件时解锁加密的私钥。如果私钥是加密的，那么 NGINX 需要密码才能使用它，密码错误会导致nginx启动或者重新加载失败。 语法 Syntax: ssl_password_file file; Default: — Context: http, server This directive appeared in version 1.7.3. ``：指定包含密码的文件路径。这个文件应该包含一个用于解锁 SSL 私钥的密码。 指定一个包含密钥密码的文件，每个密码都位于单独的一行。在加载密钥时，密码将按顺序尝试。 默认值 默认情况下，ssl_password_file 指令不被启用，即没有设置密码文件。 使用场景 该指令通常在以下情况下使用： 1. 私钥加密：当生成 SSL/TLS 私钥时，如果你为私钥设置了密码保护，那么每次 NGINX 启动时，都需要提供密码才能加载私钥。 配置示例 生成四组自签名证书及私钥， 其中RSA算法两个， ECC算法两个，两组证书中一个带密码，一个不带密码。使用脚本生成 #!/bin/bash # Set directory variables CERTS_DIR="/etc/nginx/ssl" # Create the certificate directory if it doesn't exist mkdir -p $CERTS_DIR # Set passwords for different key types PASSWORD_RSA_WITH="password123" PASSWORD_ECC_WITH="password789" # Create password files for multiple certificates echo $PASSWORD_RSA_WITH > "$CERTS_DIR/rsa_password.txt" chmod 600 "$CERTS_DIR/rsa_password.txt" echo $PASSWORD_ECC_WITH > "$CERTS_DIR/ecc_password.txt" chmod 600 "$CERTS_DIR/ecc_password.txt" cat "$CERTS_DIR/rsa_password.txt" "$CERTS_DIR/ecc_password.txt" > "$CERTS_DIR/password_file.txt" # Set certificate information COUNTRY="CN" STATE="BEIJING" LOCALITY="BEIJING" ORG="test" ORG_UNIT="test-unit" EMAIL="email@example.com" # Generate RSA private key with password openssl genpkey -algorithm RSA -aes256 -out "$CERTS_DIR/rsa_private_key_with_password.pem" -pass pass:$PASSWORD_RSA_WITH echo "Generated RSA private key with password: rsa_private_key_with_password.pem" # Generate RSA private key without password openssl genpkey -algorithm RSA -out "$CERTS_DIR/rsa_private_key_without_password.pem" echo "Generated RSA private key without password: rsa_private_key_without_password.pem" # Generate RSA Certificate Signing Request (CSR) with password, avoiding interactive input COMMON_NAME="example1.com" openssl req -new -key "$CERTS_DIR/rsa_private_key_with_password.pem" -out "$CERTS_DIR/rsa_csr_with_password.pem" \ -passin pass:$PASSWORD_RSA_WITH \ -subj "/C=$COUNTRY/ST=$STATE/L=$LOCALITY/O=$ORG/OU=$ORG_UNIT/CN=$COMMON_NAME/emailAddress=$EMAIL" echo "Generated RSA CSR with password: rsa_csr_with_password.pem" # Generate RSA CSR without password, avoiding interactive input COMMON_NAME="example2.com" openssl req -new -key "$CERTS_DIR/rsa_private_key_without_password.pem" -out "$CERTS_DIR/rsa_csr_without_password.pem" \ -subj "/C=$COUNTRY/ST=$STATE/L=$LOCALITY/O=$ORG/OU=$ORG_UNIT/CN=$COMMON_NAME/emailAddress=$EMAIL" echo "Generated RSA CSR without password: rsa_csr_without_password.pem" # Use the RSA private key to sign the certificate openssl x509 -req -in "$CERTS_DIR/rsa_csr_with_password.pem" -signkey "$CERTS_DIR/rsa_private_key_with_password.pem" -out "$CERTS_DIR/rsa_certificate_with_password.pem" -days 365 -passin pass:$PASSWORD_RSA_WITH openssl x509 -req -in "$CERTS_DIR/rsa_csr_without_password.pem" -signkey "$CERTS_DIR/rsa_private_key_without_password.pem" -out "$CERTS_DIR/rsa_certificate_without_password.pem" -days 365 echo "Generated RSA certificates" # Generate ECC private key with password openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -aes256 -out "$CERTS_DIR/ecc_private_key_with_password.pem" -pass pass:$PASSWORD_ECC_WITH echo "Generated ECC private key with password: ecc_private_key_with_password.pem" # Generate ECC private key without password openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out "$CERTS_DIR/ecc_private_key_without_password.pem" echo "Generated ECC private key without password: ecc_private_key_without_password.pem" # Generate ECC CSR with password, avoiding interactive input COMMON_NAME="example3.com" openssl req -new -key "$CERTS_DIR/ecc_private_key_with_password.pem" -out "$CERTS_DIR/ecc_csr_with_password.pem" \ -passin pass:$PASSWORD_ECC_WITH \ -subj "/C=$COUNTRY/ST=$STATE/L=$LOCALITY/O=$ORG/OU=$ORG_UNIT/CN=$COMMON_NAME/emailAddress=$EMAIL" echo "Generated ECC CSR with password: ecc_csr_with_password.pem" # Generate ECC CSR without password, avoiding interactive input COMMON_NAME="example4.com" openssl req -new -key "$CERTS_DIR/ecc_private_key_without_password.pem" -out "$CERTS_DIR/ecc_csr_without_password.pem" \ -subj "/C=$COUNTRY/ST=$STATE/L=$LOCALITY/O=$ORG/OU=$ORG_UNIT/CN=$COMMON_NAME/emailAddress=$EMAIL" echo "Generated ECC CSR without password: ecc_csr_without_password.pem" # Use the ECC private key to sign the certificate openssl x509 -req -in "$CERTS_DIR/ecc_csr_with_password.pem" -signkey "$CERTS_DIR/ecc_private_key_with_password.pem" -out "$CERTS_DIR/ecc_certificate_with_password.pem" -days 365 -passin pass:$PASSWORD_ECC_WITH openssl x509 -req -in "$CERTS_DIR/ecc_csr_without_password.pem" -signkey "$CERTS_DIR/ecc_private_key_without_password.pem" -out "$CERTS_DIR/ecc_certificate_without_password.pem" -days 365 echo "Generated ECC certificates" # Print the generated file paths echo "RSA Certificate (with password): $CERTS_DIR/rsa_certificate_with_password.pem" echo "RSA Private Key (with password): $CERTS_DIR/rsa_private_key_with_password.pem" echo "RSA Certificate (without password): $CERTS_DIR/rsa_certificate_without_password.pem" echo "RSA Private Key (without password): $CERTS_DIR/rsa_private_key_without_password.pem" echo "ECC Certificate (with password): $CERTS_DIR/ecc_certificate_with_password.pem" echo "ECC Private Key (with password): $CERTS_DIR/ecc_private_key_with_password.pem" echo "ECC Certificate (without password): $CERTS_DIR/ecc_certificate_without_password.pem" echo "ECC Private Key (without password): $CERTS_DIR/ecc_private_key_without_password.pem" ssl_password_file 来指定该文件： ...

NGINX中收到HTTP请求大小相关的错误,以下典型错误及相关解决方案。 nginx 配置文件 nginx.conf user root; worker_processes 1; error_log logs/error.log debug; #pid logs/nginx.pid; events { worker_connections 1024; } http { #large_client_header_buffers 4 16k; server { listen 80; server_name localhost; location / { root /root/nginx-quic/html; index index.html index.htm; } } } 1. 请求头超长（HTTP 400/414） HTTP 400 (Bad Request)：请求头过大，导致无法解析。 HTTP 414 (URI Too Long)：请求行（URI 部分）过长。 模拟请求头超长 curl -v -H "$(head -c 8192 < /dev/zero | tr '\0' 'A'): value" http://localhost 此命令发送一个包含 8192 个字符的请求头字段, 返回结果 < HTTP/1.1 400 Bad Request < Server: nginx/1.25.4 < Date: Sat, 23 Nov 2024 13:26:23 GMT < Content-Type: text/html < Content-Length: 233 < Connection: close 检查 error.log，通常会看到类似以下错误： ...

Common NGINX HTTP Request Size Errors and Their Solutions Here is a sample nginx.conf configuration file: user root; worker_processes 1; error_log logs/error.log debug; #pid logs/nginx.pid; events { worker_connections 1024; } http { #large_client_header_buffers 4 16k; server { listen 80; server_name localhost; location / { root /root/nginx-quic/html; index index.html index.htm; } } } 1. Oversized Request Headers (HTTP 400/414) HTTP 400 (Bad Request): The request headers are too large and cannot be parsed. HTTP 414 (URI Too Long): The request line (URI) is excessively long. Simulating Oversized Request Headers You can use the following command to simulate a request with an overly large header: ...

rfc6265中描述 4.1.2.6. The HttpOnly Attribute The HttpOnly attribute limits the scope of the cookie to HTTP requests. In particular, the attribute instructs the user agent to omit the cookie when providing access to cookies via "non-HTTP" APIs (such as a web browser API that exposes cookies to scripts). Note that the HttpOnly attribute is independent of the Secure attribute: a cookie can have both the HttpOnly and the Secure attribute. https://datatracker.ietf.org/doc/html/rfc6265 ...

shell中如果定义多行的字符串可以使用heredoc 先检查一下当前使用shell echo $0 -bash heredoc 是一种在 Shell 脚本、编程语言（例如 Bash、PHP、Ruby 等）中，用来定义多行字符串的方法。它可以使代码中的字符串定义更加清晰和可读，尤其适用于需要定义包含多行内容的文本块时。以下是 heredoc 的基本用法和一些示例。 Bash 中的 Heredoc 语法 在 Bash 中，heredoc 的语法如下： command <<EOF 内容... EOF command 表示你要将这些多行内容传递给的命令，例如 cat、echo 等。 &lt;&lt;EOF 表示开始使用 heredoc，其中 EOF 是一个标识符，用来定义多行文本的结束位置。你可以使用其他标识符来替代 EOF，例如 END，但开始和结束的标识符必须一致。 结束标识符必须单独一行，且通常没有前后的空格。 示例 1. 输出多行文本 你可以使用 heredoc 来输出多行文本： cat <<EOF 这是第一行 这是第二行 这是第三行 EOF 输出结果为： 这是第一行 这是第二行 这是第三行 2. 写入文件 你可以将 heredoc 的内容重定向到一个文件： cat < myfile.txt 这是要写入文件的内容 第二行 第三行 EOF 这会将文本块写入名为 myfile.txt 的文件中。 3. 结合命令 也可以将 heredoc 与其他命令结合使用，例如 while 循环： ...

在应用服务日志中看到了服务器日志记录错误NumberFormatExeception input string ^@^@^@^@，对于 ^@ 这个控制字符没有什么映像了于是vi打开一个临时文件 ctrl + V, ctrl + @ 输入到文件中然后hexdump 看了一下二进制内容发现是 0000000 0a00 0000002 本来输入一个字符变成两个了， （不过当时错误判断这个值就是0xa了换行符） 。vi编辑的时候会自动向文件中插入LF。可以输入其他字符比如a，结果是下面这样。 0000000 0a61 0000002 下面程序打印了ascii码， 1-31，127是控制字符 #include <stdio.h> void print_control_char(char c) { // 打印控制字符的可见形式 if (c >= 0 && c <= 31) { printf("^%c", c + 64); // 显示为 ^@, ^A, ..., ^Z 等 } else if (c == 127) { printf("^?"); // DEL字符显示为 ^? } else { printf(" "); // 非控制字符为空 } } int main() { printf("+-----+--------+--------+--------------+\n"); printf("| Dec | Hex | Char | Visible Form |\n"); printf("+-----+--------+--------+--------------+\n"); // 打印所有控制字符 (0-31, 127) for (int i = 0; i <= 127; i++) { if (i <= 31 || i == 127) { // 构造可见形式的字符串 char visibleForm[4] = " "; // 初始化为空字符串 if (i <= 31) { visibleForm[0] = '^'; visibleForm[1] = i + 64; // 转换为可见形式（如 ^A） } else if (i == 127) { visibleForm[0] = '^'; visibleForm[1] = '?'; // DEL字符的可见形式为 ^? } // 打印表格行 printf("| %3d | 0x%02X | %c | %-12s |\n", i, i, (i == 127 ? '?' : ' '), visibleForm); printf("+-----+--------+--------+--------------+\n"); } } return 0; } ...

中间证书 中间证书的使用是随着公共密钥基础设施（PKI）的发展而逐渐普及。 早期数字证书体系中根证书直接签发终端（客户端）证书，这种方式存在的问题 根证书安全风险: 一旦根证书泄露整个信任体系就会崩溃； 证书管理的灵活性：根证书通常有大型认证机构管理，工作不能合理分发； 证书撤销机制：仅用根证书签发，一旦撤销将影响整个信任链； 相关标准 X.509 证书标准： X.509 v3 证书标准中， 引入了更多扩展字段，使得中间证书可以更有效地运作。它允许通过设置 basicConstraints 扩展来定义证书是否是一个证书颁发机构（CA）证书，并引入路径长度约束（pathlen），以确保中间证书不能签发超出其级别的证书。 X.509 v3 是证书链中的关键标准，它允许将证书分层，使得根证书签发中间证书，中间证书再签发终端证书。这一机制在 1996 年被纳入 X.509 v3 标准。 互联网工程任务组 (IETF) 标准：RFC 5280： RFC 5280 是互联网标准的一个重要文档，它详细说明了证书路径验证的标准，定义了如何使用 X.509 证书和证书吊销列表（CRL）来建立信任链。 X.509 v3 侧重于定义证书和结构， RFC 5280 侧重于在互联网应用中的使用，包括如何处理证书路径验证和证书撤销。 记得刚工作时正赶上银行收单系统一机一密改造，为每个终端生成终端密钥，与PKI体系不同，当时的pos和收单系统终端大多用的还是对称加密体系。 收单终端签到会根据其对应终端主密钥生成工作密钥，用于保护用户密码和用于报文校验。最早的终端密钥用的都是各省一个， 后来为每个终端生成一个终端主密钥， 防止主密钥泄露导致全省密钥泄露。 其实大体改造思路和中间正式类似。 实际使用 看下实际网站证书使用情况 # openssl s_client -connect baidu.com:443 -showcerts CONNECTED(00000003) depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, CN = DigiCert Secure Site Pro CN CA G3 verify return:1 depth=0 C = CN, ST = \E5\8C\97\E4\BA\AC\E5\B8\82, O = "BeiJing Baidu Netcom Science Technology Co., Ltd", CN = www.baidu.cn verify return:1 --- Certificate chain 0 s:C = CN, ST = \E5\8C\97\E4\BA\AC\E5\B8\82, O = "BeiJing Baidu Netcom Science Technology Co., Ltd", CN = www.baidu.cn i:C = US, O = DigiCert Inc, CN = DigiCert Secure Site Pro CN CA G3 -----BEGIN CERTIFICATE----- ....PMdeTgwOzn2nJhPcJFZ5yUGPZ8thorOYjMLHQ4DKsy7mnGMnKLwmz17L/0Tx 8GU= -----END CERTIFICATE----- 1 s:C = US, O = DigiCert Inc, CN = DigiCert Secure Site Pro CN CA G3 i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA -----BEGIN CERTIFICATE----- ....+AgqbDB91mdnxIr1MuTtHGn/Q1YE2x9OSTb2f2k0ArhFxFdcjKTfLLewG1xD -----END CERTIFICATE----- --- Server certificate subject=C = CN, ST = \E5\8C\97\E4\BA\AC\E5\B8\82, O = "BeiJing Baidu Netcom Science Technology Co., Ltd", CN = www.baidu.cn issuer=C = US, O = DigiCert Inc, CN = DigiCert Secure Site Pro CN CA G3 --- 根证书（depth=2）：由 DigiCert 签发，是整个信任链的起点，受操作系统或浏览器信任。 中间证书（depth=1）：DigiCert 的中间 CA，用于签发百度的终端服务器证书。 服务器证书（depth=0）：这是百度的具体服务器证书，表明它属于 www.baidu.cn，并由 DigiCert 的中间 CA 签发。 ...

项目自签名证书，common name 超过64个字节报错 # openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 3650 -nodes -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=01234567890123456789012345678901234567890123456789012345678901234" Generating a RSA private key ........................++++ ........................................++++ writing new private key to 'key.pem' ----- problems making Certificate Request 140059529942848:error:0D07A097:asn1 encoding routines:ASN1_mbstring_ncopy:string too long:crypto/asn1/a_mbstr.c:107:maxsize=64 Common Name在 RFC5280中有描述（https://datatracker.ietf.org/doc/html/rfc5280#appendix-A） -- Naming attributes of type X520CommonName id-at-commonName AttributeType ::= { id-at 3 } -- Naming attributes of type X520CommonName: -- X520CommonName ::= DirectoryName (SIZE (1..ub-common-name)) -- -- Expanded to avoid parameterized type: X520CommonName ::= CHOICE { teletexString TeletexString (SIZE (1..ub-common-name)), printableString PrintableString (SIZE (1..ub-common-name)), universalString UniversalString (SIZE (1..ub-common-name)), utf8String UTF8String (SIZE (1..ub-common-name)), bmpString BMPString (SIZE (1..ub-common-name)) } 可以看到ub-common-name就是其长度定义， 当然也有一系列定义。 ...

arp_filter： 控制系统对不同网络接口上收到的 ARP 请求的响应行为 取值范围： 1 - 允许您在同一子网上拥有多个网络接口，并根据内核是否会从ARP请求的IP地址出路由数据包来决定是否应答ARP请求（因此，这需要使用基于源的路由来实现）。换句话说，它允许控制哪些网卡（通常是一个）将响应ARP请求。 0 - （默认）内核可以用其他接口的地址来响应ARP请求。这看似不正确，但通常是有意义的，因为它增加了成功通信的机会。在Linux上，IP地址是由整个主机拥有的，而不是特定的接口拥有。只有在更复杂的设置中，如负载均衡，这种行为才会引起问题。如果设置了conf/{all,interface}/arp_filter中的至少一个为TRUE，那么该接口的arp_filter将被启用，否则将被禁用 验证 还是使用负载均衡的环境， rs1地址 # ip netns exec rs1 ip a 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 10.1.1.10/32 scope global lo valid_lft forever preferred_lft forever 264: veth-rs1@if263: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:11:22:33:44:99 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.1.1.13/24 scope global veth-rs1 valid_lft forever preferred_lft forever inet 10.1.1.11/24 scope global secondary veth-rs1 valid_lft forever preferred_lft forever 271: veth-rs1-extra@if270: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 66:82:27:71:76:15 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 172.168.1.3/24 scope global veth-rs1-extra valid_lft forever preferred_lft foreversshezh 设置arp_ignore, arp_filter为默认值0 ...