Trước khi cài đặt chứng chỉ chúng ta nên kiểm tra xem liệu các chứng chỉ nhận được thực tế đã phù hợp và có thể dùng để thẩm định web server được chưa:
openssl verify -CAfile /path/to/trusted_ca.crt -purpose sslserver server.crt
Cũng như thế, nếu nó chạy tốt thì hãy chắc chắn rằng chứng chỉ có tương ứng với khoá private của web server được tạo trước đó hay không (kết quả của cả hai câu lệnh sau giống hệt nhau):
openssl x509 -noout -modulus -in server.crt | openssl sha1 openssl rsa -noout -modulus -in server.key | openssl sha1 (Còn nữa)
Phương thức 3: Chứng chỉ kí bởi một CA nội bộ
Phương thức thứ ba của chứng chỉ được kí này có thể được dùng trong mạng Intranets cũng giống như tất cả các tổ chức khác dùng, hay có kế hoạch dùng bộ thẩm định chứng chỉ của riêng họ. Trong trường hợp này, chứng chỉ CA nội bộ phải được cài đặt trên tất cả các web browser kết nối tới an ninh của web server.
chứng chỉ của CA và nơi lưu trữ cho các khoá mới.
Chú ý: CA nội bộ nên được tạo ra trên máy chủ phân tán, không kết nối chút nào đến mạng. Hệ điều hành chỉ cho phép truy cập đối với những ngưòi đã qua kiểm định và tự bản thân bộ máy đặt trong mức an toàn vật lí. Khoá private của CA là phần tử đáng kể nhất của toàn bộ hệ thống PKI. Nếu khoá này được thông qua thì tất cả chứng chỉ khác được kí bởi CA cũng xem như được thông qua.
Chúng ta sẽ dùng thư viện OpenSSL để cài đặt môi trường từng bước một như danh sách dưới đây. Tất nhiên, nếu chúng ta đã có một CA nội bộ, chúng ta có thể bỏ qua phần này và chuyển sang việc tạo các yêu cầu chứng chỉ cho web server.
1. Chuẩn bị cấu trúc thư mục cho CA mới (biến số môi trường $SSLDIR nên thêm vào bản khởi động tương xứng, chẳng hạn như /etc/profile or /etc/rc.local):
export SSLDIR=$HOME/ca mkdir $SSLDIR mkdir $SSLDIR/certs mkdir $SSLDIR/crl mkdir $SSLDIR/newcerts mkdir $SSLDIR/private mkdir $SSLDIR/requests touch $SSLDIR/index.txt echo "01" > $SSLDIR/serial chmod 700 $SSLDIR
2. Tạo file cấu hình OpenSSL chính $SSLDIR/openssl.cnf với nội dung sau (tối ưu cho cách dùng với web server SSL):
# =================================================# OpenSSL configuration file # OpenSSL configuration file
# =================================================RANDFILE = $ENV::SSLDIR/.rnd RANDFILE = $ENV::SSLDIR/.rnd [ ca ] default_ca = CA_default [ CA_default ] dir = $ENV::SSLDIR certs = $dir/certs new_certs_dir = $dir/newcerts crl_dir = $dir/crl database = $dir/index.txt private_key = $dir/private/ca.key certificate = $dir/ca.crt serial = $dir/serial crl = $dir/crl.pem RANDFILE = $dir/private/.rand default_days = 365
default_crl_days = 30 default_md = sha1 preserve = no policy = policy_anything name_opt = ca_default cert_opt = ca_default [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] default_bits = 1024 default_md = sha1 default_keyfile = privkey.pem distinguished_name = req_distinguished_name x509_extensions = v3_ca string_mask = nombstr [ req_distinguished_name ]
countryName = Country Name (2 letter code) countryName_min = 2country
Name_max = 2
stateOrProvinceName = State or Province Name (full name) localityName = Locality Name (eg, city)
0.organizationName = Organization Name (eg, company)
organizationalUnitName = Organizational Unit Name (eg, section) commonName = Common Name (eg, YOUR name)
commonName_max = 64
emailAddress = Email Addressemail Address_max = 64 [ usr_cert ] basicConstraints = CA:FALSE # nsCaRevocationUrl = https://url-to-exposed-clr-list/crl.pem [ ssl_server ] basicConstraints = CA:FALSE nsCertType = server
keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth, nsSGC, msSGC
nsComment = "OpenSSL Certificate for SSL Web Server" [ ssl_client ]
basicConstraints = CA:FALSE nsCertType = client
keyUsage = digitalSignature, keyEnciphermen textendedKeyUsage = clientAuth
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment [ v3_ca ]
basicConstraints = critical, CA:true, pathlen:0 nsCertType = sslCA
keyUsage = cRLSign, keyCertSign
extendedKeyUsage = serverAuth, clientAuth nsComment = "OpenSSL CA Certificate" [ crl_ext ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment nsComment = "OpenSSL generated CRL"
3. Bây giờ tạo ra cặp khoá public/private của CA và chứng chỉ CA tự kí: openssl req \ -config $SSLDIR/openssl.cnf \ -new \ -x509 \ -days 3652 \ -sha1 \ -newkey rsa:1024 \ -keyout $SSLDIR/private/ca.key \ -out $SSLDIR/ca.crt \
-subj '/O=Seccure/OU=Seccure Root CA'
4. Cần nhấn mạnh rằng khoá private của CA (ca.key) có thể được bảo vệ bằng một cụm mật khẩu khó tưởng tượng ra và nên có thời gian hợp lệ lâu hơn so với các chứng chỉ thông thường (chẳng hạn như 10 -30 năm hoặc hơn).
Chứng chỉ của CA “ca.crt’ nên được công bố trên trang web của Intranet và cài đặt trên mọi web browser có thể cần dùng nó. Một ví dụ về chứng chỉ CA gốc cài đặt trên Internet Explorer được thể hiện trên hình minh hoạ 2:
Hình 2. Ví dụ cài đặt chứng chỉ CA gốc trên Internet Explorer.
Từ điểm này, giờ chúng ta có thể dùng CA nội bộ để kí hoặc thu hồi chứng chỉ. Để tạo ra chứng chỉ web server , chúng ta nên theo các bước sau:
1. Tạo cặp khoá private/public của web server (server.key), và yêu cầu chứng chỉ (request.pem). Phần giới thiệu nay cần được thực thi trên web server.
openssl req \ -new \ -sha1 \ -newkey rsa:1024 \ -nodes \ -keyout server.key \ -out request.pem \
-subj '/O=Seccure/OU=Seccure Labs/CN=www.seccure.lab'
2. Copy yêu cầu chứng chỉ ở trên (request.pem) vào thư mục $SSLDIR/requests trên máy trạm của CA (dùng các phương tiện di động, chẳng hạn như ổ USB)
3. Kí các yêu cầu chứng chỉ như sau (chỉ để thực thi trên máy trạm CA): openssl ca \ -config $SSLDIR/openssl.cnf \ -policy policy_anything \ -extensions ssl_server \ -out $SSLDIR/requests/signed.pem \ -infiles $SSLDIR/requests/request.pem
4. Kết quả của câu lệnh trên là một chứng chỉ kí (signed.pem) được đặt vào thư mục
$SSLDIR/newcerts, và trong file $SSLDIR/signed.pem. Nó bao gồm cả một bản thể hiện kiểu
TXT và PEM của chứng chỉ. Bởi vì Apache muốn có kiểu định dạng thuần PEM, nên chúng ta cần chuyền đổi nó như sau:
openssl x509 \
-in $SSLDIR/requests/signed.pem \ -out $SSLDIR/requests/server.crt
5. Copy chứng chỉ mã hoá dạng PEM đã kí (server.crt) trở lại máy web server machine. Bây giờ chứng chỉ của web server đã sẵn sàng để dùng.
Với bộ thẩm định chứng chỉ nội bộ, nếu chứng chỉ của web server đạt được thì CA có trách nhiệm thu hồi chứng chỉ. Sau đó thông báo cho người dùng và các chương trình ứng dụng biết chứng chỉ này không được dùng nữa.
Để thu hồi, chúng ta cần tìm dãy số của chứng chỉ mà chúng ta muốn trong file $SSLDIR/index.txt . Sau đó có thể thu hồi như sau:
openssl ca \
-config $SSLDIR/openssl.cnf \ -revoke $SSLDIR/newcerts/.pem
Để tạo ra một file CRL (Certificate Revocation List), chúng ta có thể dùng các câu lệnh sau: openssl ca -config $SSLDIR/openssl.cnf -gencrl -crlexts crl_ext -md sha1 -out $SSLDIR/crl.pem
File trên nên được công bố trên website của CA và phân phối cho người dùng. Khi phân phối CRLs chúng ta cũng nên dùng giao thức Online Certificate Status Protocol (OCSP). Để biết thêm thông tin về OCSP, bạn có thể tìm trong RFC 2560 .
Chú ý rằng một số đường dẫn (bao gồm cả Firefox) chỉ chấp nhận CRLs mã hoá dạng DER, Vì thế trước khi cài đặt file crl.pem chúng ta phải chuyển đổi như sau:
openssl crl \
-in $SSLDIR/crl.pem \
-out $SSLDIR/revoke_certs.crl \ -outform DER
Cũng chú ý rằng để web browser kiểm tra chứng chỉ của web server có bị thu hồi hay không, tuỳ chọn “Check for server certificate revocation” nên được đánh dấu trong phần Settings của MS Internet Explorer. Nó được chỉ ra trong hình 3 và 4 như sau:
Hình 3. Cấu hình Internet Explorer để kiểm tra việc thu hồi chứng chỉ.
Hình 4. Trả lời của Internet Explorer's với một chứng chỉ bị thu hồi.
Cài đặt chứng chỉ
Tại thời điểm này chúng ta có thể tiến tới cài đặt khoá private của web server (server.key) và chứng chỉ (server.crt) vào môi trường Apache:
install -m 600 -o root -g sys server.key /usr/local/apache2/conf/ssl.key/
install -m 644 -o root -g sys server.crt /usr/local/apache2/conf/ssl.crt/
Chúng ta cũng nên chắc rằng các hưỡng dẫn trong file cấu hình của Apache đang trỏ tới file trên (trong httpd.conf).
SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key Bước cuối cùng là khởi động lại Apache để các thay đổi có hiệu quả:
/usr/local/apache2/bin/apachectl stop /usr/local/apache2/bin/apachectl startssl
Bây giờ chúng ta có thể kiểm tra xem liệu website SSL có được chấp nhân từ các web browser hay không. Và liệu các web browser có thể thẩm định web server thành công hay không. Lần này sẽ không có các cảnh báo như trong hình 5:
Hình 5. Kết nối an toàn với một chứng chỉ phù hợp.
Tổng kết phần II
Phần này đã hướng dẫn các bạn làm thế nào để cấu hình mod_ssl, tạo và dùng chứng chỉ
sẽ thảo luận việc thẩm định client thông qua các chứng chỉ cũng như các lỗi thông thường và các kiểu tấn công phổ biến có thể đe doạ đến an ninh của truyền thông SSL.
Phần III
Giới thiệu phần III
Bài này kết thúc loạt ba bài giới thiệu về cách cấu hình Apache 2.0 hỗ trợ giao thức SSL/TLS để an ninh tối đa và thực thi tối ưu cho SSL dựa trên các giao dịch thương mại điện tử.
Phần I giới thiệu các khía cạnh về khóa của SSL/TLS, và chỉ ra làm cách nào để biên dịch, cài đặt, và cấu hình Apache 2.0. Phần II mô tả cấu hình của mod_ssl và các nguồn thẩm định. Đồng thời chỉ ra làm thế nào để tạo được các chứng chỉ SSL của web server.
Bây giờ, trong phần III và cũng là phần cuối cùng của bài này, chúng ta sẽ xem đến bộ thẩm định client, dùng các chứng chỉ client. Đồng thời chúng ta sẽ biết được làm cách nào để chroot một Apache an toàn, thảo luận các phương hướng tẫn công. Sau đó là mô tả các lỗi cấu hình điển hình của các nhà quản trị làm giảm mức an toàn của truyền thông SSL.
Bộ thẩm định Client (Client Authentication)
Một phương thức phổ biến nhất để xác định người dùng trong các ứng dụng web là mật khẩu, nhóm mật khẩu hay PIN, theo nghĩa khác là “điều gì đó mà chỉ bạn biết”. “Lợi thế lớn nhất của một trong các phương thức này là sự đơn giản”. Với một nhà quản trị, điều đó đủ để thêm vào một file hướng dẫn trong http.conf và tạo ra một file mật khẩu để thực hiện như là một sơ đồ. Thật không may, chính sự đơn giản của mật khẩu lại là điểm yếu cho một số cuộc tấn công. Chúng có thể đoán, “đánh hơi” qua điện tín, chương trình brute-forced đánh cắp (chẳng hạn như khi người dùng ghi mật khẩu trên một ghi chú) hay dụ dỗ nói ra (qua một số mail về nghiên cứu xã hội hay một số loại phương thức “phishing”). Đó chính là lý do tại sao bộ thẩm định mật khẩu tiêu chuẩn lại bị xem như là yếu hơn so với việc dùng các mật khẩu một lần, mã phẫn cứng hay các dạng thẩm định khác.
Một vài người nhận ra rằng, khi dùng web server SSL, có một phương thức mạnh hơn với bộ thẩm định người dùng: các chứng chỉ SSLclient, hay các chứng chỉ “cá nhân” cho mỗi người dùng. Trong phương thức này, chúng ta có thể kiểm định người dùng web dựa trên “một số điều bạn có”. Đó là dùng một chứng chỉ và một khoá private tương ứng với các chứng chỉ client, cũng giống như “một số điều bạn biết”, là cụm mật khẩu với khoá private. Do đó, dùng các chứng chỉ thì an toàn hơn là giải pháp mật khẩu tiêu chuẩn, chủ yếu là vì một kẻ phá hoại sẽ phải cần hai phần của bộ thẩm định (khoá private tương ứng với chứng chỉ người dùng và cụm mật khẩu) để lấy được quyền truy cập. Hơn nữa, không giống như một mật khẩu chuẩn, cụm mật khẩu của chứng chỉ không thực sự được gửi qua mạng chút nào. Nó chỉ được sử dụng trên mạng cục bộ để giải mã khoá private.
Phần sau sẽ chỉ ra cách thức thực hiện của phương thức thẩm định này không phức tạp. Nó chỉ trong vài bước. Người quản trị có thể thấy nó hầu như dễ hơn các phương thức mật khẩu kiểm định cơ bản thông thường.
Cấu hình Apache để dùng chứng chỉ client
Để cấu hình Apache hỗ trợ bộ kiểm định client qua chứng chỉ X.509v3, chúng ta cần thực hiện 4 việc sau: