-
Notifications
You must be signed in to change notification settings - Fork 281
Description
Hello!
- Vote on this issue by adding a 👍 reaction
- If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)
Issue details
It would a nice addition to support inspecting certificates that use explicit TLS (StartTLS negotiates a potential upgrade to TLS from a cleartext connection), which could use a flag like --starttls
to indicate the connection uses StartTLS instead of implicit TLS:
step certificate inspect --starttls smtp.example.com:587
Related was an issue that lead to adding a smtps://
scheme prefix implying port 465 (implicit TLS), but SMTPS was commonly associated to implicit TLS equivalent to port 25 (StartTLS), however in 2018 was reassigned via RFC 8314 as the implicit TLS equivalent to the submission port (587 with StartTLS). So I don't know how much value that's providing vs just being explicit with a port number 😅 (there's help output with the smtps://
scheme, but no indication of the associated port)
Why is this needed?
The main benefit is it would not require an alternative tool to acquire a certificate from services only reachable via StartTLS:
openssl s_client -starttls smtp -connect smtp.example.com:587
StartTLS is often found with mail servers (aka explicit TLS via ports 25 and 587 related to SMTP and 110 + 143 for POP3/IMAP), which don't always offer implicit TLS ports (465, 993, 995). It can also be found elsewhere like Postgres databases (although this now offers implicit TLS too).
From what I understand however, supporting StartTLS varies by protocol, so implementing support may not be worth the effort/maintenance burden if it cannot be offloaded via some existing library? OpenSSL documents a -starttls
option with a fairly long list of supported protocols.