- Replace client.badssl.com tests with unit tests for parseTlsAlertNumber and getTlsAlertName
- Export helper functions for testing
- Keep one integration test for connection success scenario
Error messages could be translated, but TLS alert names (e.g., certificate_required)
are from RFC 8446 spec and should remain in English for consistency.
- Use i18n-t for description with code tag and RFC 8446 spec link
- Add comment that TLS alert names are from spec (not translatable)
- Refactor TCP monitor into smaller functions:
- checkTcp() for standard TCP connectivity check
- performStartTls() for STARTTLS handshake
- checkTlsCertificate() for TLS certificate validation
- attemptTlsConnection() for TLS connection with alert capture
- Improve error messages with more context
Per CommanderStorm's feedback, instead of creating a separate TLS monitor
type, add the TLS alert checking functionality directly to the existing
TCP monitor.
Changes:
- Add TLS_ALERT_CODES, parseTlsAlertNumber(), getTlsAlertName() to tcp.js
- Add checkTlsAlert() method to TCPMonitorType for mTLS verification
- Add 'Expected TLS Alert' dropdown to TCP monitor UI
- Remove separate TLS monitor type (tls.js)
This allows users to verify mTLS endpoints reject connections without
client certificates by expecting specific TLS alerts like
'certificate_required'.
Closes#5837
Add a new TLS monitor type that allows monitoring mTLS endpoints to verify
they properly reject connections without client certificates.
Features:
- New TLS monitor type with hostname and port configuration
- Expected TLS Alert dropdown to specify which TLS alert to expect
- Support for certificate_required (116) alert for mTLS verification
- Optional certificate expiry monitoring when connection succeeds
- Ignore TLS errors option
Closes#5837
Per CommanderStorm's feedback, refactor the check() method into:
- checkKeyword() - for legacy keyword matching
- checkJsonQuery() - for legacy JSONata query
- checkConditions() - for new conditions system
Also add test cases for MQTT conditions:
- Message condition with contains operator
- Topic condition with equals operator
- Condition mismatch rejection
- Multiple conditions with AND logic
This improves readability and maintainability.
Add rich conditions support to MQTT monitor similar to DNS monitor,
allowing users to define flexible conditions on:
- topic: The MQTT topic that received the message
- message: The raw message content
- json_value: JSONata-extracted value from JSON payloads
This provides a more intuitive and powerful way to validate MQTT
messages compared to the basic keyword/json-query checks.
Maintains backward compatibility with existing keyword and json-query
check types.
Closes#5992
