ldns-dane - Trực tuyến trên đám mây

CHƯƠNG TRÌNH:

TÊN

ldns-dane - xác minh hoặc tạo xác thực TLS với DANE (RFC6698)

SYNOPSIS

ldns-dane [TÙY CHỌN] xác minh tên cổng
ldns-dane [TÙY CHỌN] -t tlsafile xác minh

ldns-dane [TÙY CHỌN] tên cổng tạo
[ Chứng chỉ sử dụng [ Chọn [ Loại phù hợp ]]]

ldns-dane -h
ldns-dane -v

MÔ TẢ

Ở dạng đầu tiên: Một kết nối TLS tới tên:cổng được thành lập. Tài nguyên TLSA
(các) bản ghi cho tên được sử dụng để xác thực kết nối.

Ở dạng thứ hai: (Các) bản ghi TLSA được đọc từ tlsafile và được sử dụng để xác thực
Dịch vụ TLS mà họ tham khảo.

Ở dạng thứ ba: Một kết nối TLS tới tên:cổng được thiết lập và sử dụng để tạo
(Các) bản ghi tài nguyên TLSA sẽ xác thực kết nối. Các tham số cho TLSA
tạo rr là:

Chứng chỉ sử dụng:
0 ràng buộc CA
1 Ràng buộc chứng chỉ dịch vụ
2 Xác nhận neo tin cậy
3 Chứng chỉ do miền cấp (mặc định)

Chọn:
0 Chứng chỉ đầy đủ (mặc định)
1 chủ đềPublicKeyInfo

Loại phù hợp:
0 Không sử dụng hàm băm
1 SHA-256 (mặc định)
2 SHA-512

Thay vì các số, một số chữ cái đầu tiên của giá trị có thể được sử dụng. Ngoại trừ hàm băm
tên thuật toán, trong đó tên đầy đủ phải được chỉ định.

LỰA CHỌN

-4 TLS chỉ kết nối IPv4

-6 TLS chỉ kết nối IPv6

-a địa chỉ
Đừng cố gắng giải quyết tên, nhưng kết nối với địa chỉ thay thế.

Tùy chọn này có thể được đưa ra nhiều lần.

-b in "tên. TYPE52 \ # kích thước dữ liệu thập lục phân"thay vì định dạng bản trình bày TLSA.

-c tập tin chứng chỉ
Không kết nối TLS với tên:cổng, nhưng xác thực (hoặc tạo bản ghi TLSA) cho
chứng chỉ (chuỗi) trong tập tin chứng chỉ thay thế.

-d Giả sử tính hợp lệ của DNSSEC ngay cả khi các bản ghi TLSA có được không an toàn hoặc
không có thật.

-f tệp CA
Sử dụng CAfile để xác thực.

-h In giúp đỡ cách sử dụng ngắn

-i Tương tác sau khi kết nối.

-k tài liệu quan trọng
Chỉ định tệp chứa DNSKEY hoặc DS rr đáng tin cậy. (Các) khóa được sử dụng khi
theo đuổi chữ ký (tức là -S được đưa ra).

Tùy chọn này có thể được đưa ra nhiều lần.

Ngoài ra, nếu -k không được chỉ định và một neo tin cậy mặc định
(/etc/unbound/root.key) tồn tại và chứa bản ghi DNSKEY hoặc DS hợp lệ, nó sẽ là
được sử dụng làm mỏ neo tin cậy.

-n làm không xác minh tên máy chủ trong chứng chỉ.

-o bù đắp
Khi tạo bản ghi tài nguyên TLSA "Xác nhận neo tin cậy", hãy chọn bù đắpth
bù đắp chứng chỉ từ cuối chuỗi xác nhận. 0 có nghĩa là cuối cùng
chứng chỉ, 1 cái nhưng cuối cùng, 2 cái thứ hai nhưng cuối cùng, v.v.

Thời Gian bù đắp là -1 (mặc định), chứng chỉ cuối cùng được sử dụng (như với 0)
PHẢI tự ký. Điều này có thể giúp đảm bảo rằng dự định (tự ký)
Trust anchor thực sự hiện diện trong chuỗi chứng chỉ máy chủ (là một DANE
yêu cầu).

-p capath
Sử dụng chứng chỉ trong capath thư mục để xác nhận.

-s Khi tạo bản ghi tài nguyên TLSA với "CA Constraint" và "Service
Chứng chỉ Ràng buộc Chứng chỉ "sử dụng chứng chỉ, không xác thực và giả sử PKIX là
có hiệu lực.

Đối với "Ràng buộc CA", điều này có nghĩa là quá trình xác minh phải kết thúc bằng bản tự ký
chứng chỉ.

-S đuổi (các) chữ ký đến một khóa đã biết.

Nếu không có tùy chọn này, mạng cục bộ được tin cậy để cung cấp trình phân giải DNSSEC
(nghĩa là bit AD được kiểm tra).

-t tlsafile
Đọc (các) bản ghi TLSA từ tlsafile. Khi nào tên và cổng cũng được cung cấp, chỉ TLSA
hồ sơ phù hợp với tên, cổng và vận chuyển được sử dụng. Nếu không thì tên chủ sở hữu
của (các) bản ghi TLSA sẽ được sử dụng để xác định tên, cổng và vận chuyển.

-Trả lại trạng thái thoát 2 cho các kết nối đã được xác thực PKIX mà không có TLSA (an toàn)
(các) hồ sơ

-u Sử dụng truyền tải UDP thay vì TCP.

-v Hiển thị phiên bản và thoát.

Sử dụng ldns-dane trực tuyến bằng các dịch vụ onworks.net