用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/CyberStrikeus/CyberStrike --skill cis-apache-7-2命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | cis-apache-7.2 |
| description | Ensure a Valid Trusted Certificate Is Installed |
| category | cis-apache |
| version | 3.6.0 |
| author | cyberstrike-official |
| tags | ["cis","apache","linux","ssl","tls","certificates","encryption"] |
| cis_id | 7.2 |
| cis_benchmark | CIS Apache HTTP Server 2.2 Benchmark v3.6.0 |
| tech_stack | ["linux","apache"] |
| cwe_ids | [] |
| chains_with | [] |
| prerequisites | [] |
| severity_boost | {} |
The default SSL certificate is self-signed and is not trusted. Install a valid certificate signed by a commonly trusted certificate authority. To be valid, the certificate must be:
Note: Some previously "Trusted" Certificate Authority certificates had been signed with a weak hash algorithm such as MD5, or SHA1. These signature algorithms are known to be vulnerable to collision attacks. Note that it's not the just the signature on the server's certificate, but any signature up the certificate chain. Such CA certificates are considered no longer trusted as of January 1, 2017.
A digital certificate on your server automatically communicates your site's authenticity to visitors' web browsers. If a trusted authority signs your certificate, it confirms for visitors they are actually communicating with you, and not with a fraudulent site stealing credit card numbers or personal information.
None documented
Perform one or more of the following steps to determine if the recommended state is implemented:
Intermediate certificate has an insecure signature. Upgrade to SHA2 as
soon as possible to avoid browser warnings.
In addition, the weak SHA1 or MD5 signature algorithm will be highlighted with red text where the additional intermediate CA certificates are enumerated. For example, the certificate below from an SSL Labs report used SHA1 for the digital signature:
If a weak signature is found, then follow your certificate authority's process for having the server certificate re-issued / re-signed, in order to ensure that it is signed with a strong digital signature.
If the server is not an external server, or is not running on the standard port 443, a vulnerability scanner such as Nessus can also be used to validate both the server certificate and the intermediate certificate chain. Custom certificate authorities may also be tested by loading the root certificate into the vulnerability scanner.
The testing can also be done by connecting to a running web server with your favorite browser and checking for a warning with regard to the certificate trust. However, some browsers may not warn of weak digital signatures, or other certificate issues.
OpenSSL can also be used to validate a certificate as a valid trusted certificate, using a trusted bundle of CA certificate. It is important that the CA bundle of certificates be an already validated and trusted file in order for the test to be valid.
$ openssl verify -CAfile /etc/ssl/certs/ca-bundle.crt -purpose
sslserver
/etc/ssl/certs/example.com.crt
/etc/ssl/certs/example.com.crt: OK
A specific error message and code will be reported in addition to the OK if the certificate is not valid, For example:
error 10 at 0 depth lookup:certificate has expired
OK
Of course, it is important here as well to be sure of the integrity of the trusted certificate authorities used by the web client. Visit the OWASP testing SSL web page for additional suggestions: https://www.owasp.org/index.php/Testing_for_SSL-TLS_%28OWASP-CM-001%29
Perform the following to implement the recommended state:
Decide on the hostname to be used for the certificate. It is important to remember that the browser will compare the hostname in the URL to the common name in the certificate, so it is important that all https: URLs match the correct hostname. Specifically, the hostname www.example.com is not the same as example.com nor the same as ssl.example.com.
Generate a private key using openssl. Although certificate key lengths of 1024 have been common in the past, a key length of 2048 is now recommended for strong authentication. The key must be kept confidential and will be encrypted with a passphrase by default. Follow the steps below and respond to the prompts for a passphrase. See the Apache or OpenSSL documentation for details:
# cd /etc/pki/tls/certs
# umask 077
# openssl genrsa -aes128 2048 > example.com.key
Generating RSA private key, 2048 bit long modulus
...+++
...........+++
e is 65537 (0x10001)
Enter pass phrase:
Verifying - Enter pass phrase:
# cp /etc/ssl/openssl.cnf ex1.cnf>
[ req ]
. . .
distinguished_name = req_distinguished_name
req_extensions = req_ext
[ req_distinguished_name ]
countryName_default = GB
stateOrProvinceName_default = Scotland
localityName_default = Glasgow
0.organizationName_default = Example Company Ltd
organizationalUnitName_default = ICT
commonName_default = www.example.com
# openssl req -new -config ex2.cnf -out example.com.csr -key
example.com.key
Enter pass phrase for example.com.key:
You are about to be asked to enter information that will be
incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a
DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:
State or Province Name (full name) [Scotland]:
Locality Name (eg, city) [Glasgow]:
Organization Name (eg, company) [Example Company Ltd]:
Organizational Unit Name (eg, section) [ICT]:
Common Name (e.g. server FQDN or YOUR name) [www.example.com]:
# openssl req -in ex2.csr -text | more
Certificate Request:
Data:
Version: 1 (0x0)
Subject: C = GB, ST = Scotland, L = Glasgow, O = Example
Company Ltd, OU = ICT, CN = www.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:cb:c2:7a:04:13:19:7a:c0:74:00:63:dd:e9:6e:
. . . <snip> . . .
3a:9d:aa:50:09:4a:40:48:b4:e2:24:ef:fa:7b:42:
a4:33
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Subject Alternative Name:
DNS:www.example.com, DNS:example.com,
DNS:app.example.com, DNS:ws.example.com
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
Signature Algorithm: sha256WithRSAEncryption
73:f0:e3:90:a7:ab:01:e4:7f:12:19:b7:6a:dd:be:4e:5c:f1:
. . .
# mv www.example.com.key /etc/ssl/private/
Send the certificate signing request (CSR) to a certificate signing authority to be signed, and follow their instructions for submission and validation. The CSR and the final signed certificate are just encoded text and need to be protected for integrity, but not confidentiality. This certificate will be given out for every SSL connection made.
The resulting signed certificate may be named www.example.com.crt and placed in /etc/ssl/certs/ as readable by root (umask 444). Please note that the certificate authority does not need the private key (example.com.key) and this file must be carefully protected. With a decrypted copy of the private key, it would be possible to decrypt all conversations with the server.
Do not forget the passphrase used to encrypt the private key. It will be required every time the server is started in https mode. If it is necessary to avoid requiring an administrator having to type the passphrase every time the httpd service is started, the private key may be stored in clear text. Storing the private key in clear text increases the convenience while increasing the risk of disclosure of the key, but may be appropriate for the sake of being able to restart, if the risks are well managed. Be sure that the key file is only readable by root. To decrypt the private key and store it in clear text file the following openssl command may be used. You can tell by the private key headers whether it is encrypted or clear text.
# cd /etc/ssl/private/
# umask 077
SSLCertificateFile /etc/ssl/certs/example.com.crt
SSLCertificateKeyFile /etc/ssl/private/example.com.key
# Default CA file, can be concatenated with your CA certificate.
SSLCertificateChainFile /etc/ssl/certs/server-chain.crt
Version 6
14.2 Encrypt All Sensitive Information Over Less-trusted Networks All communication of sensitive information over less-trusted networks should be encrypted. Whenever information flows over a network with a lower trust level, the information should be encrypted.
Version 7
14.4 Encrypt All Sensitive Information in Transit Encrypt all sensitive information in transit.
Level 1 | Scored Level 2 | Scored