Cách tạo khóa khách hàng VPN và gửi CSR để ký

Sớm hay muộn, một người dùng VPN sẽ đề nghị gửi khóa riêng tư qua email để quản trị viên có thể tạo chứng chỉ, và chính lời đề nghị đó là thứ phải từ chối. Quy trình hiệu quả giữ khóa tại máy khách ngay từ lệnh đầu tiên: máy khách tạo khóa, gửi yêu cầu ký chứng chỉ, bên phát hành xác minh và cấp quyền, và chứng chỉ đã ký quay về nằm cạnh khóa đã tạo ra nó. Danh sách kiểm tra dưới đây thất bại theo hướng đóng ở mỗi bước, và đó chính là điểm mấu chốt, vì hai trong năm bước là những bước người ta thường bỏ qua khi vội.

Bước 1: tạo khóa ngay tại nơi nó sẽ sống

Hãy tạo trên máy sẽ giữ khóa và để nó ở đó. Khóa phần mềm nằm trong một tệp có quyền hạn chế chặt chẽ; khóa dựa trên phần cứng hoặc trong kho được quản lý thì không bao giờ trở thành tệp, và đường đăng ký của nó thường là một công cụ riêng chứ không phải lệnh OpenSSL. Dù thế nào, không ai cần nhìn thấy nửa riêng tư.

Luồng phần mềm trông như sau, với khóa và yêu cầu được tạo trong một phiên:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

Dòng umask quan trọng hơn vẻ ngoài của nó. Không có nó, khóa được ghi ở dạng mọi người đều đọc được trên một hệ thống cho phép mặc định, và việc sao chép tệp sau đó sẽ lan truyền điều đó. Dùng lại một khóa sẵn có là hợp lý khi nó đã được bảo vệ và phù hợp với chính sách của bạn; tạo khóa mới cho từng thiết bị dễ biện minh hơn.

Bước 2: đặt danh tính vào yêu cầu, không phải vào email

Hãy quyết định VPN thực sự xác thực điều gì trước khi yêu cầu được tạo, vì câu trả lời đó thuộc vào bên trong CSR. OpenVPN theo truyền thống gắn danh tính máy khách với tên chung của chứng chỉ, và những công cụ như strongSwan so khớp chuỗi danh tính với chủ thể hoặc tên thay thế của chủ thể. Một email nói rằng tên tôi là alice không phải bằng chứng, và một yêu cầu có chủ thể nói điều tương tự chỉ tốt hơn một chút.

Thêm tên thay thế của chủ thể khi trình xác minh của bạn kiểm tra một tên, vì việc so khớp hiện đại thường bỏ qua CN cũ:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

Giữ CN ngắn, ổn định và gắn với tài khoản thay vì gắn với mẫu laptop. Một cái tên chứa số sê-ri thiết bị của người dùng là vấn đề hỗ trợ đang chờ lần thay phần cứng đầu tiên.

Bước 3: xác minh yêu cầu trước khi ký

Bên phát hành xác minh hai điều khác nhau, và trộn lẫn chúng là sai lầm kinh điển. Thứ nhất, yêu cầu nhất quán về nội bộ: chữ ký được xác minh dựa trên khóa công khai mà nó mang theo. Thứ hai, người yêu cầu có quyền với điều mà yêu cầu đòi hỏi, và không kiểm tra mật mã nào trả lời được điều đó.

Phần máy móc là một lệnh, và nó nên in kết quả xác minh cùng với chủ thể:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

Hãy để ý điều đó chứng minh gì. Một yêu cầu được xác minh chỉ cho thấy người gửi đã giữ khóa riêng tư khớp tại thời điểm gửi; nó không chứng minh người gửi là người được nêu trong chủ thể, và nó không cấp quyền truy cập nhóm hoặc tuyến đường đang được yêu cầu. Xem xét đăng ký là một cổng riêng, và một yêu cầu về nhóm mà không ai phê duyệt nên bị từ chối thay vì bị sửa một cách lặng lẽ.

Bước 4: cấp quyền, rồi ký với phần mở rộng rõ ràng

Ký là nơi CA quyết định chính sách thay vì chấp nhận yêu cầu nguyên văn. Hiệu lực, mục đích sử dụng khóa và phần mở rộng vai trò thuộc về một tệp phần mở rộng, không phải những giá trị mặc định mà bạn sẽ không nhớ sau sáu tháng. Chứng chỉ máy khách cho xác thực VPN cần xác thực máy khách làm mục đích của nó.

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

Dùng -CAserial với tệp số sê-ri sẵn có nếu đã có một tệp đang dùng, và giữ khóa CA ngoại tuyến hoặc trong kho được bảo vệ mà chính sách của bạn nêu tên. Số sê-ri chứng chỉ phải là duy nhất cho mỗi bên phát hành; tạo lại tệp sê-ri từ đầu có nguy cơ va chạm khiến việc thu hồi trở nên mơ hồ.

Ghi lại những gì đã cấp: số sê-ri, chủ thể, danh tính được yêu cầu, người phê duyệt và ngày hết hạn. Bản ghi đó là thứ mà một quyết định thu hồi sau này dựa vào, và nó không thể được dựng lại chỉ từ chứng chỉ nếu dấu vết đăng ký chỉ sống trong một hộp thư.

Bước 5: cài đặt nó cạnh khóa khớp và chứng minh cặp khóa

Máy khách nhận chứng chỉ và chuỗi của bên phát hành, không bao giờ là khóa. Trước khi kết nối, hãy xác nhận rằng chứng chỉ thực sự ghép cặp với khóa đã có trên đĩa, vì một cặp không khớp tạo ra lỗi bắt tay khó hiểu rất lâu sau đó:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

Hai bản tóm tắt phải khớp nhau. Sau đó kết nối và xác nhận rằng danh tính mà máy chủ ghi lại là danh tính bạn đã cấp quyền, chứ không chỉ là đường hầm đã lên. Nếu khóa bị mất hoặc thiết bị được thay, câu trả lời là thu hồi cộng với một yêu cầu mới từ thiết bị mới; đề nghị quản trị viên gửi trả một khóa từ nơi khác không khôi phục bản gốc và lặng lẽ phá vỡ mô hình đã khiến yêu cầu trở nên an toàn.