Tôi đang thêm hỗ trợ HTTPS cho thiết bị Linux nhúng. Tôi đã cố gắng tạo chứng chỉ tự ký với các bước sau:

openssl req -new > cert.csr
openssl rsa -in privkey.pem -out key.pem
openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 1001
cat key.pem>>cert.pem

Điều này hoạt động, nhưng tôi gặp một số lỗi với, ví dụ như Google Chrome:

Đây có lẽ không phải là trang web bạn đang tìm kiếm!
Chứng chỉ an toàn của trang web không đáng tin cậy!

Tui bỏ lỡ điều gì vậy? Đây có phải là cách chính xác để xây dựng một chứng chỉ tự ký?

Bạn có thể làm điều đó trong một lệnh:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

Bạn cũng có thể thêm -nodes(viết tắt no DES) nếu bạn không muốn bảo vệ khóa riêng của mình bằng cụm mật khẩu. Nếu không, nó sẽ nhắc bạn nhập mật khẩu "ít nhất 4 ký tự".

Các daystham số (365), bạn có thể thay thế bằng bất kỳ số ảnh hưởng đến ngày hết hạn. Sau đó, nó sẽ nhắc bạn về những thứ như "Tên quốc gia", nhưng bạn chỉ cần nhấn Entervà chấp nhận mặc định.

Thêm vào -subj '/CN=localhost'để loại bỏ các câu hỏi về nội dung của chứng chỉ (thay thế localhostbằng tên miền bạn muốn).

Chứng chỉ tự ký không được xác thực với bất kỳ bên thứ ba nào trừ khi bạn nhập chúng vào trình duyệt trước đó. Nếu bạn cần bảo mật hơn, bạn nên sử dụng chứng chỉ được ký bởi cơ quan cấp chứng chỉ (CA).

Tui bỏ lỡ điều gì vậy? Đây có phải là cách chính xác để xây dựng một chứng chỉ tự ký?

Thật dễ dàng để tạo một chứng chỉ tự ký. Bạn chỉ cần sử dụng openssl reqlệnh. Thật khó để tạo ra một thứ có thể được sử dụng bởi sự lựa chọn lớn nhất của các máy khách, như các trình duyệt và các công cụ dòng lệnh.

Điều này thật khó khăn vì các trình duyệt có các yêu cầu riêng và chúng hạn chế hơn IETF . Các yêu cầu được sử dụng bởi các trình duyệt được ghi lại tại Diễn đàn CA / Trình duyệt (xem tài liệu tham khảo bên dưới). Các hạn chế phát sinh trong hai lĩnh vực chính: (1) neo tin cậy và (2) tên DNS.

Các trình duyệt hiện đại (như warez chúng tôi đang sử dụng vào năm 2014/2015) muốn có một chứng chỉ gắn lại với một neo tin cậy và họ muốn các tên DNS được trình bày theo những cách cụ thể trong chứng chỉ. Và các trình duyệt đang tích cực di chuyển chống lại chứng chỉ máy chủ tự ký.

Một số trình duyệt không chính xác giúp bạn dễ dàng nhập chứng chỉ máy chủ tự ký. Thực tế, bạn không thể với một số trình duyệt, như trình duyệt của Android. Vì vậy, giải pháp hoàn chỉnh là trở thành chính quyền của bạn.

Trong trường hợp không trở thành chính quyền của bạn, bạn phải có được tên DNS để cung cấp cho chứng chỉ cơ hội thành công lớn nhất. Nhưng tôi sẽ khuyến khích bạn trở thành chính quyền của bạn. Thật dễ dàng để trở thành chính quyền của bạn, và nó sẽ vượt qua tất cả các vấn đề về niềm tin (ai tin tưởng hơn chính bạn?).

Đây có lẽ không phải là trang web bạn đang tìm kiếm!
Chứng chỉ an toàn của trang web không đáng tin cậy!

Điều này là do các trình duyệt sử dụng danh sách các neo tin cậy được xác định trước để xác thực chứng chỉ máy chủ. Chứng chỉ tự ký không xâu chuỗi trở lại một mỏ neo đáng tin cậy.

Cách tốt nhất để tránh điều này là:

1. Tạo thẩm quyền của riêng bạn (nghĩa là trở thành CA )
2. Tạo yêu cầu ký chứng chỉ (CSR) cho máy chủ
3. Ký CSR của máy chủ bằng khóa CA của bạn
4. Cài đặt chứng chỉ máy chủ trên máy chủ
5. Cài đặt chứng chỉ CA trên máy khách

Bước 1 - Tạo thẩm quyền của riêng bạn chỉ có nghĩa là tạo chứng chỉ tự ký với CA: truevà sử dụng khóa thích hợp. Điều đó có nghĩa là Chủ thể và Nhà phát hành là cùng một thực thể, CA được đặt thành đúng trong các ràng buộc cơ bản (nó cũng phải được đánh dấu là quan trọng), việc sử dụng khóa là keyCertSignvà crlSign(nếu bạn đang sử dụng CRL) và Mã định danh khóa chủ đề (SKI) là giống như Mã định danh khóa thẩm quyền (AKI).

Để trở thành cơ quan cấp chứng chỉ của riêng bạn, hãy xem * Làm thế nào để bạn ký yêu cầu ký chứng chỉ với cơ quan chứng nhận của bạn? trên Stack Overflow. Sau đó, nhập CA của bạn vào Cửa hàng ủy thác được trình duyệt sử dụng.

Bước 2 - 4 gần như là những gì bạn làm bây giờ cho một máy chủ đối mặt công khai khi bạn tranh thủ các dịch vụ của CA như Startcom hoặc CAcert . Bước 1 và 5 cho phép bạn tránh quyền hạn của bên thứ ba và đóng vai trò là người có thẩm quyền của riêng bạn (ai tin tưởng hơn chính bạn?).

Cách tốt nhất tiếp theo để tránh cảnh báo của trình duyệt là tin tưởng vào chứng chỉ của máy chủ. Nhưng một số trình duyệt, như trình duyệt mặc định của Android, không cho phép bạn làm điều đó. Vì vậy, nó sẽ không bao giờ hoạt động trên nền tảng.

Vấn đề trình duyệt (và các tác nhân người dùng tương tự khác) không tin tưởng các chứng chỉ tự ký sẽ là một vấn đề lớn trong Internet of Things (IoT). Ví dụ, điều gì sẽ xảy ra khi bạn kết nối với bộ điều chỉnh nhiệt hoặc tủ lạnh để lập trình nó? Câu trả lời là, không có gì tốt khi có liên quan đến trải nghiệm người dùng.

Nhóm làm việc WebAppSec của W3C đang bắt đầu xem xét vấn đề. Xem, ví dụ : Đề xuất: Đánh dấu HTTP là không an toàn .

Cách tạo chứng chỉ tự ký với OpenSSL

Các lệnh bên dưới và tệp cấu hình tạo chứng chỉ tự ký (nó cũng chỉ cho bạn cách tạo yêu cầu ký). Chúng khác với các câu trả lời khác ở một khía cạnh: tên DNS được sử dụng cho chứng chỉ tự ký có trong Tên thay thế chủ đề (SAN) và không phải là Tên chung (CN) .

Tên DNS được đặt trong SAN thông qua tệp cấu hình với dòng subjectAltName = @alternate_names(không có cách nào để thực hiện thông qua dòng lệnh). Sau đó, có một alternate_namesphần trong tệp cấu hình (bạn nên điều chỉnh phần này cho phù hợp với sở thích của bạn):

[ alternate_names ]

DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# IP.1        = 127.0.0.1
# IP.2        = ::1

Điều quan trọng là phải đặt tên DNS trong SAN chứ không phải CN, bởi vì cả IETF và Diễn đàn CA / Trình duyệt đều chỉ định thực tiễn. Họ cũng chỉ định rằng tên DNS trong CN không được chấp nhận (nhưng không bị cấm). Nếu bạn đặt tên DNS trong CN, thì nó phải được đưa vào SAN theo chính sách CA / B. Vì vậy, bạn không thể tránh sử dụng Tên thay thế chủ đề.

Nếu bạn không đặt tên DNS trong SAN, thì chứng chỉ sẽ không thể xác thực theo trình duyệt và các tác nhân người dùng khác tuân theo hướng dẫn của Diễn đàn CA / Trình duyệt.

Liên quan: các trình duyệt tuân theo các chính sách của CA / Browser Forum; và không phải là chính sách của IETF. Đó là một trong những lý do chứng chỉ được tạo bằng OpenSSL (thường đi theo IETF) đôi khi không xác thực theo trình duyệt (trình duyệt tuân theo CA / B). Chúng là các tiêu chuẩn khác nhau, chúng có các chính sách ban hành khác nhau và các yêu cầu xác nhận khác nhau.

Tạo chứng chỉ tự ký (chú ý thêm -x509tùy chọn):

openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes \
    -keyout example-com.key.pem -days 365 -out example-com.cert.pem

Tạo một yêu cầu ký (lưu ý thiếu -x509tùy chọn):

openssl req -config example-com.conf -new -sha256 -newkey rsa:2048 -nodes \
    -keyout example-com.key.pem -days 365 -out example-com.req.pem

In chứng chỉ tự ký :

openssl x509 -in example-com.cert.pem -text -noout

In một yêu cầu ký :

openssl req -in example-com.req.pem -text -noout

Tập tin cấu hình (thông qua -configtùy chọn)

[ req ]
default_bits        = 2048
default_keyfile     = server-key.pem
distinguished_name  = subject
req_extensions      = req_ext
x509_extensions     = x509_ext
string_mask         = utf8only

# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
#   Its sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName         = Country Name (2 letter code)
countryName_default     = US

stateOrProvinceName     = State or Province Name (full name)
stateOrProvinceName_default = NY

localityName            = Locality Name (eg, city)
localityName_default        = New York

organizationName         = Organization Name (eg, company)
organizationName_default    = Example, LLC

# Use a friendly name here because it's presented to the user. The server's DNS
#   names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
#   by both IETF and CA/Browser Forums. If you place a DNS name here, then you
#   must include the DNS name in the SAN too (otherwise, Chrome and others that
#   strictly follow the CA/Browser Baseline Requirements will fail).
commonName          = Common Name (e.g. server FQDN or YOUR name)
commonName_default      = Example Company

emailAddress            = Email Address
emailAddress_default        = test@example.com

# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]

subjectKeyIdentifier        = hash
authorityKeyIdentifier    = keyid,issuer

# You only need digitalSignature below. *If* you don't allow
#   RSA Key transport (i.e., you use ephemeral cipher suites), then
#   omit keyEncipherment because that's key transport.
basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage    = serverAuth, clientAuth

# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]

subjectKeyIdentifier        = hash

basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage    = serverAuth, clientAuth

[ alternate_names ]

DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       = 127.0.0.1

# IPv6 localhost
# DNS.8     = ::1

Bạn có thể cần thực hiện các thao tác sau cho Chrome. Nếu không, Chrome có thể khiếu nại Tên chung không hợp lệ ( ERR_CERT_COMMON_NAME_INVALID) . Tôi không chắc mối quan hệ giữa địa chỉ IP trong SAN và CN trong trường hợp này là gì.

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

Có các quy tắc khác liên quan đến việc xử lý tên DNS trong chứng chỉ X.509 / PKIX. Tham khảo các tài liệu này cho các quy tắc:

• Hồ sơ RFC 5280, Internet X.509 Chứng chỉ cơ sở hạ tầng khóa và danh sách thu hồi chứng chỉ (CRL)
• RFC 6125, Đại diện và Xác minh Nhận dạng dịch vụ ứng dụng dựa trên tên miền trong Cơ sở hạ tầng khóa công khai trên Internet bằng chứng chỉ X.509 (PKIX) trong bối cảnh bảo mật lớp vận chuyển (TLS)
• RFC 6797, Phụ lục A, Bảo mật vận chuyển nghiêm ngặt HTTP (HSTS)
• RFC 7469, Phần mở rộng ghim khóa công khai cho HTTP
• CA / Trình duyệt diễn đàn Yêu cầu cơ bản
• Diễn đàn CA / Trình duyệt Hướng dẫn xác thực mở rộng

RFC 6797 và RFC 7469 được liệt kê, vì chúng hạn chế hơn các tài liệu RFC và CA / B khác. RFC 6797 và 7469 cũng không cho phép địa chỉ IP.

Dưới đây là các tùy chọn được mô tả trong câu trả lời của @ diegows , được mô tả chi tiết hơn, từ tài liệu :

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX

req

Yêu cầu chứng chỉ PKCS # 10 và tiện ích tạo chứng chỉ.

-x509

tùy chọn này xuất ra một chứng chỉ tự ký thay vì yêu cầu chứng chỉ. Điều này thường được sử dụng để tạo chứng chỉ kiểm tra hoặc CA gốc tự ký.

-newkey arg

tùy chọn này tạo một yêu cầu chứng chỉ mới và khóa riêng mới. Đối số có một trong một số hình thức. rsa: nbits , trong đó nbits là số bit, tạo ra một khóa RSA nbits có kích thước.

-keyout filename

cái này cung cấp tên tệp để ghi khóa riêng vừa tạo.

-out filename

Cái này chỉ định tên tệp đầu ra để ghi vào hoặc đầu ra tiêu chuẩn theo mặc định.

-days n

khi tùy chọn -x509 đang được sử dụng, điều này chỉ định số ngày để chứng nhận chứng chỉ. Mặc định là 30 ngày.

-nodes

nếu tùy chọn này được chỉ định thì nếu khóa riêng được tạo, nó sẽ không được mã hóa.

Các tài liệu thực sự chi tiết hơn so với ở trên; Tôi chỉ tóm tắt ở đây.

Kể từ năm 2020, lệnh sau phục vụ tất cả các nhu cầu của bạn, bao gồm SAN:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
  -keyout example.key -out example.crt -extensions san -config \
  <(echo "[req]"; 
    echo distinguished_name=req; 
    echo "[san]"; 
    echo subjectAltName=DNS:example.com,DNS:example.net,IP:10.0.0.1
    ) \
  -subj "/CN=example.com"

Trong OpenSSL ≥ 1.1.1, điều này có thể được rút ngắn thành:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
  -keyout example.key -out example.crt -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:example.net,IP:10.0.0.1"

Nó tạo ra một chứng chỉ

• hợp lệ cho các miền example.comvà example.net(SAN),
• cũng hợp lệ cho địa chỉ IP 10.0.0.1(SAN),
• tương đối mạnh (tính đến năm 2020) và
• có giá trị trong nhiều 3650ngày (~ 10 năm).

Nó tạo ra các tập tin sau:

• Khóa riêng: example.key
• Chứng chỉ: example.crt

Tất cả thông tin được cung cấp tại dòng lệnh. Không có đầu vào tương tác làm phiền bạn. Không có tập tin cấu hình nào bạn phải loay hoay với. Tất cả các bước cần thiết được thực hiện bằng một lệnh gọi OpenSSL duy nhất : từ việc tạo khóa riêng cho đến chứng chỉ tự ký.

Ghi chú số 1: Thông số về tiền điện tử

Vì chứng chỉ là tự ký và cần được người dùng chấp nhận theo cách thủ công, nên không có ý nghĩa gì khi sử dụng hết hạn ngắn hoặc mật mã yếu.

Trong tương lai, bạn có thể muốn sử dụng nhiều hơn 4096bit cho khóa RSA và thuật toán băm mạnh hơn sha256, nhưng đến năm 2020 đây là các giá trị lành mạnh. Chúng đủ mạnh trong khi được hỗ trợ bởi tất cả các trình duyệt hiện đại.

Ghi chú # 2: Tham số " -nodes"

Về mặt lý thuyết bạn có thể bỏ qua -nodestham số (có nghĩa là "không mã hóa DES"), trong trường hợp đó example.keysẽ được mã hóa bằng mật khẩu. Tuy nhiên, điều này hầu như không bao giờ hữu ích cho việc cài đặt máy chủ, bởi vì bạn cũng sẽ phải lưu mật khẩu trên máy chủ hoặc bạn phải nhập thủ công vào mỗi lần khởi động lại.

Ghi chú # 3: Xem thêm

• Cung cấp topicAltName để openssl trực tiếp trên dòng lệnh
• Làm cách nào để thêm nhiều địa chỉ email vào chứng chỉ SSL thông qua dòng lệnh?
• Thông tin thêm về MSYS_NO_PATHCONV

Tôi không thể bình luận, vì vậy tôi sẽ đặt đây là một câu trả lời riêng biệt. Tôi tìm thấy một vài vấn đề với câu trả lời một lót được chấp nhận:

• Một lớp lót bao gồm một cụm mật khẩu trong khóa.
• Một lớp lót sử dụng SHA-1 trong nhiều trình duyệt đưa ra các cảnh báo trong bảng điều khiển.

Dưới đây là phiên bản đơn giản hóa loại bỏ cụm mật khẩu, tăng tính bảo mật để chặn các cảnh báo và bao gồm một gợi ý trong các nhận xét để chuyển trong -subj để xóa danh sách câu hỏi đầy đủ:

openssl genrsa -out server.key 2048
openssl rsa -in server.key -out server.key
openssl req -sha256 -new -key server.key -out server.csr -subj '/CN=localhost'
openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt

Thay thế 'localhost' bằng bất kỳ tên miền nào bạn yêu cầu. Bạn sẽ cần chạy hai lệnh đầu tiên lần lượt vì OpenSSL sẽ nhắc nhập cụm mật khẩu.

Để kết hợp cả hai thành một tệp .pem:

cat server.crt server.key > cert.pem

Các trình duyệt hiện đại hiện có lỗi bảo mật đối với các chứng chỉ tự ký được hình thành tốt nếu chúng thiếu SAN (Tên thay thế chủ đề). OpenSSL không cung cấp một cách dòng lệnh để chỉ định điều này , vì vậy nhiều hướng dẫn và dấu trang của nhà phát triển đột nhiên bị lỗi thời.

Cách nhanh nhất để chạy lại là một tệp conf ngắn, độc lập:

1. Tạo tệp cấu hình OpenSSL (ví dụ req.cnf:)

   [req]
   distinguished_name = req_distinguished_name
   x509_extensions = v3_req
   prompt = no
   [req_distinguished_name]
   C = US
   ST = VA
   L = SomeCity
   O = MyCompany
   OU = MyDivision
   CN = www.company.com
   [v3_req]
   keyUsage = critical, digitalSignature, keyAgreement
   extendedKeyUsage = serverAuth
   subjectAltName = @alt_names
   [alt_names]
   DNS.1 = www.company.com
   DNS.2 = company.com
   DNS.3 = company.net
   

2. Tạo chứng chỉ tham chiếu tệp cấu hình này

   openssl req -x509 -nodes -days 730 -newkey rsa:2048 \
    -keyout cert.key -out cert.pem -config req.cnf -sha256
   

Cấu hình ví dụ từ https://support.citrix.com/article/CTX135602

Tôi khuyên bạn nên thêm tham số -sha256 , để sử dụng thuật toán băm SHA-2, bởi vì các trình duyệt chính đang xem xét để hiển thị "chứng chỉ SHA-1" là không an toàn.

Dòng lệnh tương tự từ câu trả lời được chấp nhận - @diegows có thêm -sha256

openssl req -x509 -sha256 -newkey rsa: 2048 -keyout key.pem -out cert.pem -days XXX

Thêm thông tin trong blog Google Security .

Cập nhật tháng 5 năm 2018. Như nhiều người lưu ý trong các nhận xét rằng việc sử dụng SHA-2 không thêm bất kỳ bảo mật nào vào chứng chỉ tự ký. Nhưng tôi vẫn khuyên bạn nên sử dụng nó như một thói quen tốt của việc không sử dụng các hàm băm mật mã lỗi thời / không an toàn. Giải thích đầy đủ có sẵn trong Tại sao các chứng chỉ trên chứng chỉ cuối thực thể lại dựa trên SHA-1? .

Đây là tập lệnh tôi sử dụng trên các hộp cục bộ để đặt SAN (objectAltName) trong các chứng chỉ tự ký.

Tập lệnh này lấy tên miền (example.com) và tạo SAN cho * .example.com và example.com trong cùng một chứng chỉ. Các phần dưới đây được bình luận. Đặt tên cho kịch bản (ví dụ generate-ssl.sh) và cấp cho nó quyền thực thi. Các tập tin sẽ được ghi vào cùng thư mục với tập lệnh.

Chrome 58 trở đi yêu cầu SAN phải được đặt trong chứng chỉ tự ký.

#!/usr/bin/env bash

# Set the TLD domain we want to use
BASE_DOMAIN="example.com"

# Days for the cert to live
DAYS=1095

# A blank passphrase
PASSPHRASE=""

# Generated configuration file
CONFIG_FILE="config.txt"

cat > $CONFIG_FILE <<-EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
x509_extensions = v3_req
distinguished_name = dn

[dn]
C = CA
ST = BC
L = Vancouver
O = Example Corp
OU = Testing Domain
emailAddress = webmaster@$BASE_DOMAIN
CN = $BASE_DOMAIN

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = *.$BASE_DOMAIN
DNS.2 = $BASE_DOMAIN
EOF

# The file name can be anything
FILE_NAME="$BASE_DOMAIN"

# Remove previous keys
echo "Removing existing certs like $FILE_NAME.*"
chmod 770 $FILE_NAME.*
rm $FILE_NAME.*

echo "Generating certs for $BASE_DOMAIN"

# Generate our Private Key, CSR and Certificate
# Use SHA-2 as SHA-1 is unsupported from Jan 1, 2017

openssl req -new -x509 -newkey rsa:2048 -sha256 -nodes -keyout "$FILE_NAME.key" -days $DAYS -out "$FILE_NAME.crt" -passin pass:$PASSPHRASE -config "$CONFIG_FILE"

# OPTIONAL - write an info to see the details of the generated crt
openssl x509 -noout -fingerprint -text < "$FILE_NAME.crt" > "$FILE_NAME.info"

# Protect the key
chmod 400 "$FILE_NAME.key"

Kịch bản này cũng viết một tệp thông tin, vì vậy bạn có thể kiểm tra chứng chỉ mới và xác minh SAN được đặt đúng.

                ...
                28:dd:b8:1e:34:b5:b1:44:1a:60:6d:e3:3c:5a:c4:
                da:3d
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Subject Alternative Name: 
            DNS:*.example.com, DNS:example.com
Signature Algorithm: sha256WithRSAEncryption
     3b:35:5a:d6:9e:92:4f:fc:f4:f4:87:78:cd:c7:8d:cd:8c:cc:
     ...

Nếu bạn đang sử dụng Apache, thì bạn có thể tham chiếu chứng chỉ trên trong tệp cấu hình của mình như sau:

<VirtualHost _default_:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/htdocs

    SSLEngine on
    SSLCertificateFile path/to/your/example.com.crt
    SSLCertificateKeyFile path/to/your/example.com.key
</VirtualHost>

Hãy nhớ khởi động lại máy chủ Apache (hoặc Nginx hoặc IIS) của bạn để chứng chỉ mới có hiệu lực.

2017 một lót:

openssl req \
-newkey rsa:2048 \
-x509 \
-nodes \
-keyout server.pem \
-new \
-out server.pem \
-subj /CN=localhost \
-reqexts SAN \
-extensions SAN \
-config <(cat /System/Library/OpenSSL/openssl.cnf \
    <(printf '[SAN]\nsubjectAltName=DNS:localhost')) \
-sha256 \
-days 3650

Điều này cũng hoạt động trong Chrome 57, vì nó cung cấp SAN mà không cần tệp cấu hình khác. Nó được lấy từ một câu trả lời ở đây .

Điều này tạo ra một tệp .pem duy nhất chứa cả khóa riêng và cert. Bạn có thể di chuyển chúng sang các tệp .pem riêng nếu cần.

Tôi không thể bình luận vì vậy tôi thêm một câu trả lời riêng biệt. Tôi đã cố gắng tạo chứng chỉ tự ký cho NGINX và điều đó thật dễ dàng, nhưng khi tôi muốn thêm nó vào danh sách trắng của Chrome thì tôi gặp vấn đề. Và giải pháp của tôi là tạo chứng chỉ Root và ký chứng chỉ con bởi nó.

Vì vậy, từng bước một. Tạo tệp config_ssl_ca.cnf Thông báo, tệp cấu hình có tùy chọn basicConstraint = CA: true có nghĩa là chứng chỉ này được coi là root.

Đây là một thực hành tốt, bởi vì bạn tạo nó một lần và có thể sử dụng lại.

[ req ]
default_bits = 2048

prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req

[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=root region
localityName=root city
organizationName=root organisation
organizationalUnitName=roote department
commonName=root
emailAddress=root_email@root.localhost

[ alternate_names ]
DNS.1        = market.localhost
DNS.2        = www.market.localhost
DNS.3        = mail.market.localhost
DNS.4        = ftp.market.localhost

[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:true
subjectKeyIdentifier = hash
subjectAltName = @alternate_names

Tập tin cấu hình tiếp theo cho chứng chỉ con của bạn.

[ req ]
default_bits = 2048

prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req

[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=Kyiv region
localityName=Kyiv
organizationName=market place
organizationalUnitName=market place department
commonName=FirstName LastName
emailAddress=email@market.localhost

[ alternate_names ]
DNS.1        = market.localhost
DNS.2        = www.market.localhost
DNS.3        = mail.market.localhost
DNS.4        = ftp.market.localhost

[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:false
subjectAltName = @alternate_names
subjectKeyIdentifier = hash

Bước đầu tiên - tạo khóa gốc và chứng chỉ

openssl genrsa -out ca.key 2048
openssl req -new -x509 -key ca.key -out ca.crt -days 365 -config config_ssl_ca.cnf

Bước thứ hai tạo khóa con và tệp CSR - Yêu cầu ký chứng chỉ. Bởi vì ý tưởng là ký chứng chỉ con bằng root và lấy chứng chỉ đúng

openssl genrsa -out market.key 2048
openssl req -new -sha256 -key market.key -config config_ssl.cnf -out market.csr

Mở thiết bị đầu cuối Linux và thực hiện lệnh này echo 0

echo 1 > ca.srl
touch index.txt

Các ca.srl tập tin văn bản có chứa số serial bên cạnh sử dụng trong hex. Bắt buộc. Tập tin này phải có mặt và chứa một số sê-ri hợp lệ.

Bước cuối cùng, chọn thêm một tệp cấu hình và gọi nó là config_ca.cnf

# we use 'ca' as the default section because we're usign the ca command
[ ca ]
default_ca = my_ca

[ my_ca ]
#  a text file containing the next serial number to use in hex. Mandatory.
#  This file must be present and contain a valid serial number.
serial = ./ca.srl

# the text database file to use. Mandatory. This file must be present though
# initially it will be empty.
database = ./index.txt

# specifies the directory where new certificates will be placed. Mandatory.
new_certs_dir = ./

# the file containing the CA certificate. Mandatory
certificate = ./ca.crt

# the file contaning the CA private key. Mandatory
private_key = ./ca.key

# the message digest algorithm. Remember to not use MD5
default_md = sha256

# for how many days will the signed certificate be valid
default_days = 365

# a section with a set of variables corresponding to DN fields
policy = my_policy

# MOST IMPORTANT PART OF THIS CONFIG
copy_extensions = copy

[ my_policy ]
# if the value is "match" then the field value must match the same field in the
# CA certificate. If the value is "supplied" then it must be present.
# Optional means it may be present. Any fields not mentioned are silently
# deleted.
countryName = match
stateOrProvinceName = supplied
organizationName = supplied
commonName = supplied
organizationalUnitName = optional
commonName = supplied

Bạn có thể hỏi, tại sao khó khăn như vậy, tại sao chúng ta phải tạo thêm một cấu hình để ký chứng chỉ con bằng root. Câu trả lời rất đơn giản vì chứng chỉ con phải có khối SAN - Tên thay thế chủ đề. Nếu chúng tôi ký chứng chỉ con bằng cách sử dụng "openssl x509", chứng chỉ Root sẽ xóa trường SAN trong chứng chỉ con. Vì vậy, chúng tôi sử dụng "openssl ca" thay vì "openssl x509" để tránh việc xóa trường SAN. Chúng tôi tạo một tệp cấu hình mới và yêu cầu nó sao chép tất cả các trường mở rộng copy_extensions = copy .

openssl ca -config config_ca.cnf -out market.crt -in market.csr

Chương trình hỏi bạn 2 câu hỏi: 1. Ký giấy chứng nhận? Nói "Y" 2. 1 trong số 1 yêu cầu chứng nhận được chứng nhận, cam kết? Nói "Y"

Trong thiết bị đầu cuối, bạn có thể thấy một câu có từ "Cơ sở dữ liệu", nó có nghĩa là tệp index.txt mà bạn tạo bằng lệnh "chạm". Nó sẽ chứa tất cả thông tin bởi tất cả các chứng chỉ bạn tạo bằng "openssl ca" produc. Để kiểm tra chứng chỉ sử dụng hợp lệ:

openssl rsa -in market.key -check

Nếu bạn muốn xem những gì bên trong CRT:

openssl x509 -in market.crt -text -noout

Nếu bạn muốn xem những gì bên trong CSR:

openssl req -in market.csr -noout -text 

Bạn có quy trình chung đúng. Cú pháp của lệnh dưới đây.

openssl req -new -key {private key file} -out {output file}

Tuy nhiên, các cảnh báo được hiển thị, vì trình duyệt không thể xác minh danh tính bằng cách xác thực chứng chỉ với Cơ quan cấp chứng chỉ (CA) đã biết.

Vì đây là chứng chỉ tự ký nên không có CA và bạn có thể bỏ qua cảnh báo và tiến hành một cách an toàn. Nếu bạn muốn có được một chứng chỉ thực mà bất kỳ ai cũng có thể nhận ra trên Internet thì thủ tục dưới đây.

1. Tạo khóa riêng
2. Sử dụng khóa riêng đó để tạo tệp CSR
3. Gửi CSR cho CA (Verisign hoặc người khác, v.v.)
4. Cài đặt nhận chứng chỉ từ CA trên máy chủ web
5. Thêm các certs khác vào chuỗi xác thực tùy thuộc vào loại cert

Tôi có thêm chi tiết về điều này trong một bài đăng tại Bảo mật kết nối: Tạo chứng chỉ bảo mật với OpenSSL

Một lớp lót FTW. Tôi thích giữ cho nó đơn giản. Tại sao không sử dụng một lệnh chứa TẤT CẢ các đối số cần thiết? Đây là cách tôi thích nó - điều này tạo ra chứng chỉ x509 và khóa PEM của nó:

openssl req -x509 \
 -nodes -days 365 -newkey rsa:4096 \
 -keyout self.key.pem \
 -out self-x509.crt \
 -subj "/C=US/ST=WA/L=Seattle/CN=example.com/emailAddress=someEmail@gmail.com"

Lệnh duy nhất đó chứa tất cả các câu trả lời bạn thường cung cấp cho các chi tiết chứng chỉ. Bằng cách này, bạn có thể đặt tham số và chạy lệnh, nhận đầu ra của mình - sau đó đi uống cà phê.

>> Thêm tại đây <<

Phiên bản một lót 2017:

CentOS:

openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/pki/tls/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))

Ubuntu:

openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "/CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))

Chỉnh sửa: đã thêm tùy chọn Slash vào 'subj' cho Ubuntu.

Tạo khóa

Tôi đang sử dụng /etc/mysqlđể lưu trữ cert vì /etc/apparmor.d/usr.sbin.mysqldchứa /etc/mysql/*.pem r.

sudo su -
cd /etc/mysql
openssl genrsa -out ca-key.pem 2048;
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem -out server-req.pem;
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem -out client-req.pem;
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem;

Thêm cấu hình

/etc/mysql/my.cnf

[client]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/client-cert.pem
ssl-key=/etc/mysql/client-key.pem

[mysqld]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/server-cert.pem
ssl-key=/etc/mysql/server-key.pem

Trên thiết lập của tôi, máy chủ Ubuntu đã đăng nhập vào: /var/log/mysql/error.log

Theo dõi ghi chú:

• SSL error: Unable to get certificate from '...'

  MySQL có thể bị từ chối đọc quyền truy cập vào tệp chứng chỉ của bạn nếu nó không có trong cấu hình apparmors . Như đã đề cập trong các bước trước ^, hãy lưu tất cả các chứng chỉ của chúng tôi dưới dạng .pemcác tệp trong /etc/mysql/thư mục được mặc định bởi apparmor (hoặc sửa đổi apparmor / SELinux của bạn để cho phép truy cập vào bất cứ nơi nào bạn lưu trữ chúng.)

• SSL error: Unable to get private key

  Phiên bản máy chủ MySQL của bạn có thể không hỗ trợ định rsa:2048dạng mặc định

  Chuyển đổi được tạo rsa:2048thành đơn giản rsavới:

  openssl rsa -in server-key.pem -out server-key.pem
  openssl rsa -in client-key.pem -out client-key.pem
  

• Kiểm tra xem máy chủ cục bộ có hỗ trợ SSL không :

  mysql -u root -p
  mysql> show variables like "%ssl%";
  +---------------+----------------------------+
  | Variable_name | Value                      |
  +---------------+----------------------------+
  | have_openssl  | YES                        |
  | have_ssl      | YES                        |
  | ssl_ca        | /etc/mysql/ca-cert.pem     |
  | ssl_capath    |                            |
  | ssl_cert      | /etc/mysql/server-cert.pem |
  | ssl_cipher    |                            |
  | ssl_key       | /etc/mysql/server-key.pem  |
  +---------------+----------------------------+
  

• Xác minh kết nối tới cơ sở dữ liệu được mã hóa SSL :

  Xác minh kết nối

  Khi đăng nhập vào phiên bản MySQL, bạn có thể đưa ra truy vấn:

  show status like 'Ssl_cipher';
  

  Nếu kết nối của bạn không được mã hóa, kết quả sẽ trống:

  mysql> show status like 'Ssl_cipher';
  +---------------+-------+
  | Variable_name | Value |
  +---------------+-------+
  | Ssl_cipher    |       |
  +---------------+-------+
  1 row in set (0.00 sec)
  

  Mặt khác, nó sẽ hiển thị một chuỗi có độ dài khác không cho cypher đang sử dụng:

  mysql> show status like 'Ssl_cipher';
  +---------------+--------------------+
  | Variable_name | Value              |
  +---------------+--------------------+
  | Ssl_cipher    | DHE-RSA-AES256-SHA |
  +---------------+--------------------+
  1 row in set (0.00 sec)
  

• Yêu cầu ssl cho kết nối người dùng cụ thể ('yêu cầu ssl'):

  • SSL

  Yêu cầu máy chủ chỉ cho phép kết nối được mã hóa SSL cho tài khoản.

  GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost'
    REQUIRE SSL;
  

  Để kết nối, máy khách phải chỉ định tùy chọn --ssl-ca để xác thực chứng chỉ máy chủ và có thể chỉ định thêm các tùy chọn --ssl-key và --ssl-cert. Nếu tùy chọn --ssl-ca và tùy chọn --ssl-capath không được chỉ định, máy khách sẽ không xác thực chứng chỉ máy chủ.

Liên kết thay thế: Hướng dẫn dài dòng trong Kết nối PHP an toàn với MySQL bằng SSL .

Như đã được thảo luận chi tiết, chứng chỉ tự ký không được tin cậy cho Internet . Bạn có thể thêm chứng chỉ tự ký vào nhiều nhưng không phải tất cả các trình duyệt . Ngoài ra, bạn có thể trở thành cơ quan chứng nhận của riêng bạn .

Lý do chính khiến người ta không muốn nhận chứng chỉ đã ký từ cơ quan cấp chứng chỉ là chi phí - Symantec tính phí từ $ 995 - $ 1,999 mỗi năm cho chứng chỉ - chỉ với chứng chỉ dành cho mạng nội bộ, Symantec tính phí $ 399 mỗi năm . Chi phí đó rất dễ để biện minh nếu bạn đang xử lý thanh toán bằng thẻ tín dụng hoặc làm việc cho trung tâm lợi nhuận của một công ty có lợi nhuận cao. Nhiều người có thể chi trả cho một dự án cá nhân đang tạo trên internet hoặc phi lợi nhuận với ngân sách tối thiểu hoặc nếu một người làm việc trong một trung tâm chi phí của một tổ chức - các trung tâm chi phí luôn cố gắng làm nhiều hơn với số ít.

Một cách khác là sử dụng certbot (xem về certbot ). Certbot là một ứng dụng khách tự động dễ sử dụng, tìm nạp và triển khai các chứng chỉ SSL / TLS cho máy chủ web của bạn.

Nếu bạn thiết lập certbot, bạn có thể kích hoạt nó để tạo và duy trì chứng chỉ cho bạn do cơ quan chứng nhận Let Encrypt cấp.

Tôi đã làm điều này vào cuối tuần cho tổ chức của tôi. Tôi đã cài đặt các gói cần thiết cho certbot trên máy chủ của mình (Ubuntu 16.04) và sau đó chạy lệnh cần thiết để thiết lập và bật certbot. Một người có thể cần một plugin DNS cho certbot - chúng tôi hiện đang sử dụng DigitalOcean mặc dù có thể sẽ sớm chuyển sang dịch vụ khác.

Lưu ý rằng một số hướng dẫn không hoàn toàn đúng và mất một chút thời gian với Google để tìm ra. Điều này đã mất một khoảng thời gian hợp lý của tôi lần đầu tiên nhưng bây giờ tôi nghĩ rằng tôi có thể làm điều đó trong vài phút.

Đối với DigitalOcean, một lĩnh vực tôi gặp khó khăn là khi tôi được nhắc nhập đường dẫn đến tệp INI thông tin kỹ thuật số của bạn. Những gì tập lệnh đang đề cập đến là trang Ứng dụng & API và tab Mã thông báo / Khóa trên trang đó. Bạn cần phải có hoặc tạo mã thông báo truy cập cá nhân (đọc và viết) cho API của DigitalOcean - đây là chuỗi thập lục phân 65 ký tự. Chuỗi này sau đó cần phải được đưa vào một tệp trên máy chủ web mà bạn đang chạy certbot. Tập tin đó có thể có một nhận xét là dòng đầu tiên của nó (bình luận bắt đầu bằng #). Dòng seccond là:

dns_digitalocean_token = 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff

Khi tôi tìm ra cách thiết lập mã thông báo đọc + ghi cho API của DigitalOcean, việc sử dụng certbot để thiết lập chứng chỉ ký tự đại diện là khá dễ dàng . Lưu ý rằng người ta không phải thiết lập chứng chỉ ký tự đại diện, thay vào đó, người ta có thể chỉ định từng tên miền và tên miền phụ mà người ta muốn chứng chỉ phải xuất hiện. Đó là chứng chỉ ký tự đại diện yêu cầu tệp INI thông tin có chứa mã thông báo truy cập cá nhân từ DigitalOcean.

Lưu ý rằng chứng chỉ khóa công khai (còn được gọi là chứng chỉ nhận dạng hoặc chứng chỉ SSL) hết hạn và yêu cầu gia hạn. Do đó, bạn sẽ cần gia hạn chứng chỉ của mình trên cơ sở định kỳ (định kỳ). Các tài liệu certbot bao gồm việc gia hạn các chứng chỉ .

Kế hoạch của tôi là viết một kịch bản để sử dụng lệnh openssl để lấy ngày hết hạn chứng chỉ của tôi và kích hoạt gia hạn khi còn 30 ngày hoặc ít hơn cho đến khi hết hạn. Sau đó tôi sẽ thêm tập lệnh này vào cron và chạy nó một lần mỗi ngày.

Đây là lệnh để đọc ngày hết hạn chứng chỉ của bạn:

root@prod-host:~# /usr/bin/openssl x509 -enddate -noout -in path-to-certificate-pem-file
notAfter=May 25 19:24:12 2019 GMT