E-postkryptering: metoder, nøkler og driftsmodeller

Spørsmålet «Er denne e-posten kryptert?» er teknisk ufullstendig. En melding kan være lesbar på klienten, lagret som chiffertekst på e-postserveren, dekryptert på en gateway, beskyttet mellom to MTA-er med TLS og lagret ukryptert igjen hos mottakeren. Et solid svar oppgir derfor beskyttelsesobjekt, endepunkter, nøkkelinnehavere og klartekststeder. NIST behandler transport-, domene- og innholdsmekanismer nettopp av denne grunn som samvirkende, men separate kontroller (NIST SP 800-177 Rev. 1).

Transportkryptering beskytter en forbindelse. SMTP STARTTLS forhandles på nytt for hvert hopp og avsluttes ved den aktuelle MTA-en. Innholdskryptering beskytter en MIME-enhet med S/MIME eller OpenPGP og kan overleve flere transport- og lagringshopp. Om den faktisk fungerer ende-til-ende, avhenger ikke bare av formatet: Dersom en bedriftsgateway dekrypterer på vegne av brukeren, ligger de kryptografiske endepunktene på gatewayene og ikke hos brukerklientene (RFC 3207, RFC 8551, RFC 9580).

En digital signatur er enda en annen sikkerhetsfunksjon. Den knytter data til en privat signaturnøkkel og muliggjør integritets- og identitetskontroll; den gjør ikke innholdet hemmelig. Omvendt sier en vellykket dekryptert melding fortsatt ingenting om hvem som opprettet den. I S/MIME skilles det mellom CMS SignedData og EnvelopedData henholdsvis AuthEnvelopedData. OpenPGP skiller også mellom signatur-, øktnøkkel- og krypterte datapakker (RFC 5652, RFC 8551, S/MIME Content Types, RFC 9580, Packet Syntax).

Forklaringen følger en melding og spør ved hvert hopp hvor klartekst foreligger og hvem som kontrollerer nøklene. Transportkryptering, ende-til-ende-metoder, gatewayer, portaler, metadata, diagnostikk og gjenoppretting sammenlignes på dette grunnlaget.

E-postkryptering kan beskytte transporthoppet, meldingsinnholdet eller en portaltilgang. Disse modellene har ulike nøkkelinnehavere og ulike steder der klartekst foreligger. Artikkelen følger derfor først beskyttelsesveien og deretter de enkelte produktene og metodene.

Arkitekturtilnærming: beskyttelsesmodeller og klartekstgrenser

E-postkryptering skiller seg først og fremst ved hvilke to punkter som krypterer og dekrypterer. Tabellen starter derfor med den normale meldingsveien og viser deretter hvor klartekst teknisk sett fortsatt er synlig.

Ingen av disse modellene er generelt «sterkere». Klient-til-klient reduserer klartekststeder i infrastrukturen, men vanskeliggjør kontroll av skadelig programvare, journaling, eDiscovery og gjenoppretting. NCCoEs praktiske eksempel lar derfor S/MIME-kontrollen utføres på brukerklienten med dens Trust Anchors etter at transport- og domenebaserte kontroller er avsluttet ved MTA-en (NCCoE: DNS-Based Email Security). Gatewayer sentraliserer policy og nøkler, men blir dermed selv høyt privilegerte klartekst- og nøkkelsteder. Portaler når mottakere uten e-postkryptografi, men oppretter en ekstra metode for nett, identitet og lagring. Valget følger dataklassifisering, trusselmodell, oppbevaring, juridiske krav og kapasiteten hos begge kommunikasjonspartene – ikke produktnavnet.

SMTP-TLS: beskyttelse per transporthopp

SMTP ble opprinnelig utformet uten obligatorisk konfidensialitet. STARTTLS utvider en eksisterende SMTP-økt: Etter vellykket TLS-handshake forhandles funksjoner på nytt med EHLO. I opportunistisk modus kan den sendende MTA-en falle tilbake til klartekst dersom STARTTLS mangler eller det oppstår en sertifikatfeil. Det forbedrer beskyttelsen mot passiv avlytting, men gir uten ekstra policy ingen robust garanti mot nedgradering eller en aktiv angriper (RFC 3207).

MTA-STS publiserer først en DNS-TXT-henvisning og henter den faktiske policyen via HTTPS. I enforce-modus må de angitte MX-navnene valideres med PKIX; feil fører til forsinket levering i stedet for klartekst. DANE for SMTP knytter sertifikat- eller nøkkelinformasjon til DNSSEC-validerte TLSA-poster. REQUIRETLS er en SMTP- og meldingsmerking som lar en avsender kreve TLS for videre overføring. Disse metodene har ulike avhengigheter og rekkevidder og må ikke samles i én avkrysningsboks «TLS required» (RFC 8461, RFC 7672, RFC 8689).

SMTP TLS Reporting, TLS-RPT, gir aggregerte rapporter om vellykkede og mislykkede TLS-policykontroller. Det beviser ingen enkeltlevering og inneholder ingen melding; det bidrar til å oppdage sertifikat-, DNS- og policyfeil før køer vokser lenge. NIST anbefaler at mottaksdomener signaliserer DANE, MTA-STS eller begge deler, og beskriver de ulike avhengighetene av DNSSEC, HTTPS og PKIX (RFC 8460, NIST SP 800-177 Rev. 1, avsnitt 5.2).

SMTP-TLS avsluttes ved neste e-postserver. Dersom meldingsinnholdet skal forbli beskyttet på tvers av flere hopp, brukes meldingsrelaterte metoder som S/MIME eller OpenPGP.

S/MIME: CMS, X.509 og MIME

S/MIME er ikke ett enkelt krypteringsbibliotek, men en kombinasjon av flere standarder. MIME strukturerer meldingsdeler; CMS definerer signerte og krypterte beholdere; X.509/PKIX knytter offentlige nøkler til identiteter og tillitsankere via sertifikater. For hver mottaker krypterer avsenderen den symmetriske innholdsnøkkelen med mottakerens offentlige nøkkel eller en avtalt nøkkelhåndteringsmetode. Den tilhørende private nøkkelen kreves for å lese (RFC 8551, RFC 5652, RFC 5280).

Administratoren må skille mellom to nøkkelroller. En signaturnøkkel skal bare være tilgjengelig for undertegneren; en sentral kopi ville teknisk gjøre det mulig for tredjeparter å opprette nye signaturer under vedkommendes identitet. En dekrypteringsnøkkel kan sikres eller legges i escrow i henhold til organisasjonens policy, slik at eldre forretningsmeldinger forblir lesbare etter tap av enhet, rolleendring eller sertifikatfornyelse. RFC 8551 påpeker uttrykkelig at en person kan ha flere aktive nøkkelpar til ulike formål; NIST skiller mellom beskyttelse og gjenoppretting for hver nøkkeltype (RFC 8551, Multiple Key Pairs, NIST SP 800-57 Part 1 Rev. 5).

Før sending trenger avsenderen et egnet og gyldig krypteringssertifikat for hver mottaker. Distribusjon kan skje via en katalog, signerte meldinger, en sertifikatplattform eller manuelt. Distribusjonsgrupper er særlig krevende fordi utvidelse, synlighet og sertifikattilgjengelighet for alle medlemmer må passe sammen. Microsoft dokumenterer for Exchange attributtene userSMIMECertificate og userCertificate samt sertifikatsamlingen for tillitskontroll (Microsoft: S/MIME in Exchange Server, Microsoft: S/MIME in Exchange Online).

OpenPGP: format er ikke tillitsmodell

RFC 9580 definerer OpenPGP-pakker, nøkler, fingeravtrykk, signaturer, øktnøkler og krypterte data. En nøkkelring er ifølge standarden bare en samling av nøkler; hvordan en organisasjon finner nøkler, kontrollerer eiere og avgjør tillit, ligger utenfor dette dataformatet. Det historisk utbredte Web of Trust er derfor én mulig driftsform, men ikke en synonym definisjon av OpenPGP. Andre miljøer bruker manuelt kontrollerte fingeravtrykk, organisasjonssignerte nøkler, WKD, katalogtjenester eller sentralt administrerte gatewayer (RFC 9580, Keyrings og Fingerprints).

For e-post kapsler PGP/MIME inn signaturer og chiffertekst i MIME-strukturer. Inline-PGP beskytter derimot bare utvalgte tekstdeler og fører lett til interoperabilitetsproblemer med HTML, vedlegg, tegnsett og linjekanonisering. RFC 3156 standardiserer multipart/encrypted og multipart/signed for OpenPGP. Om en klient fullt ut støtter moderne RFC-9580-nøkler, AEAD, brukte kurver og PGP/MIME, må testes med de faktiske motpartene (RFC 3156, RFC 9580).

En kort nøkkel-ID er ikke et tilstrekkelig identitetsbevis. RFC 9580 advarer om at nøkkel-ID-er ikke må antas å være entydige; fullstendig fingeravtrykk brukes ved kontroller. Tilbakekallingssertifikater, utløp, undernøkler, nye fingeravtrykk og sikker distribusjon av en rotasjon hører derfor til samme livssyklus som første nøkkelutstedelse.

S/MIME og OpenPGP kan brukes på endeenheten eller sentralt på gatewayen. Gatewayen forenkler policy og nøkkeldrift, men får til gjengjeld tilgang til klarteksten.

Gatewaymodell: sentral policy og sentral makt over klartekst

En e-postgateway tar imot vanlige interne meldinger, klassifiserer avsender, mottaker og data, finner passende S/MIME- eller OpenPGP-nøkler og velger kryptering, signatur, TLS eller portallevering. Innkommende meldinger dekrypteres eventuelt før overlevering til det interne e-postsystemet. Produkter som SEPPmail, Totemomail eller Kiteworks EPG og HIN bruker ulike plattformer, men samme grunnleggende tillitsforskyvning: Organisasjonen delegerer kryptografi fra brukerens endepunkt til en infrastrukturkomponent (SEPPmail: produkter, HIN Mail).

Dette løser ikke nøkkeldistribusjonen av seg selv. Gatewayen trenger fortsatt en dokumentert kobling mellom mottakeridentitet og offentlig nøkkel, en prioritet mellom flere metoder, regler for utløpte eller tilbakekalte nøkler og en definert reserveprosedyre. Automatisk nøkkelutveksling mellom gatewayer kan forenkle disse trinnene, men er selv en tillitsprotokoll med motpartsidentitet, cache, utløp og feiltilstand.

Policyrekkefølgen avgjør hvilke kontroller som ser klartekst. Når en inngående gateway dekrypterer, kan anti-malware, DLP og arkivering arbeide etterpå. Dersom en utgående gateway krypterer for tidlig, er etterfølgende skannere blinde. Endrer en gateway en allerede signert MIME-enhet, kan innholds- eller DKIM-signaturen bli ugyldig. RFC 6376 gjør de kanoniserte headerne og meldingskroppen til signaturobjektet; derfor må signering, kryptering, ansvarsfraskrivelser, omskriving og DKIM ordnes i en dokumentert pipeline (RFC 6376).

Hvis ingen egnet nøkkel er tilgjengelig hos den eksterne mottakeren, kan en portal lagre meldingen og styre tilgang via nettinnlogging. Dermed går problemet fra e-postkryptografi til nettidentitet og plattformdrift.

Portallevering: nettapplikasjon i stedet for mottakernøkkel

Ved portallevering mottar mottakeren en vanlig varslingse-post og åpner det beskyttede innholdet via en nettapplikasjon. Det kryptografiske endepunktet er portalen, ikke mottakerens e-postklient. Den tekniske oppgaven flyttes dermed fra distribusjon av offentlige nøkler til nettidentitet, øktadministrasjon, lagring av meldinger og vedlegg, varslingslenke, oppbevaring og sikker svarkanal.

HIN dokumenterer som et konkret eksempel registrering, mobilnummer og SMS-kode samt muligheten til å huske en enhet for senere tilgang. Dette eksemplet dokumenterer driftsmodellen, ikke en universelt gyldig portalimplementering. Andre produkter bruker passord, engangskode via separat kanal, føderert identitet eller en eksisterende kundeinnlogging (HIN: Mail til ikke-medlemmer).

For administratorer trenger en portal minst følgende bevis:

• Hvilke data finnes i det ubeskyttede varselet og i URL-tokenet?
• Hvordan sikres førstegangsregistrering, identitetsbinding, mislykkede forsøk, å huske enhet og kontogjenoppretting?
• Hvor lagres meldinger, vedlegg, nøkler og revisjonsdata, og når slettes de?
• Kan en melding gjenopprettes etter utløp, sletting av bruker eller bytte av tenant?
• Hvordan loggføres sikkert svar, videresending, nedlasting og lesebekreftelse?
• Hva skjer når portalen ikke er tilgjengelig, SMS-tjenesten er nede eller mottakerkontoen er kompromittert?

En HTTP-status 200 beviser bare at et webgrensesnitt svarer. En syntetisk portalgjennomgang må dekke varsling, registrering eller innlogging, annen faktor, åpning, vedlegg, svar og den forventede revisjonsposten.

Metadata, headere og arkivering

Innholdskryptering beskytter ikke automatisk SMTP-konvolutten. Leverende MTA-er trenger minst mottakeradresser; systemer oppretter Received-linjer og behandler størrelses- og ruteinformasjon. Også med S/MIME forblir ytre headere normalt synlige. RFC 8551 tillater å kapsle inn en fullstendig melding som message/rfc822 i den beskyttede MIME-enheten, men krever en skillelig fremstilling av indre og ytre headere. Om emne, avsendervisning og mottakerliste faktisk er beskyttet, er en klient- og gatewayfunksjon, ikke en sikker konsekvens av låssymbolet (RFC 5322, RFC 8551, Header Protection).

Arkivering må fastsette hvilken representasjon som bevares: opprinnelig klartekst, signert originalenhet, kryptert original, dekryptert arbeidskopi eller portalobjekt. Bare klartekst forenkler eDiscovery, men mister det kryptografiske originalbeviset. Bare chiffertekst kan bli ulesbar etter nøkkeltap. Signaturvalidering på et senere tidspunkt krever opprinnelige byte, sertifikatkjede, daværende tillits- og sperreinformasjon samt et tidsgrunnlag; et sertifikat som er utløpt i dag, gjør ikke automatisk en signatur som da var gyldig verdiløs.

Livssyklus for nøkler og sertifikater

En produktiv kryptotjeneste trenger et inventar som går ut over utløpsdatoer. NIST SP 800-57 behandler generering, aktivering, beskyttelse, inventar, distribusjon, bruk, rotasjon, sperring, arkiv, gjenoppretting og destruksjon som sammenhengende administrasjonsoppgaver (NIST SP 800-57 Part 1 Rev. 5).

S/MIME-banekontroll omfatter tillitsanker, mellomsertifikater, gyldighetstid, navn eller e-postidentitet, Key Usage/Extended Key Usage, algoritme og sperrestatus. OCSP og CRL-er er igjen avhengige av nettverk og cache. Ved en soft fail kan en kontroll fortsette selv om sperreinformasjon ikke er tilgjengelig; ved hard fail kan et infrastrukturproblem blokkere alle signerte eller krypterte meldinger. Denne beslutningen hører hjemme i policyen og overvåkingen (RFC 5280, RFC 6960).

Diagnostikken starter med den valgte beskyttelsesmodellen: TLS-hopp, signatur og kryptering av innholdet eller portaltilgang. Først deretter kontrolleres sertifikat, nøkkel, policy og leveringsvei.

Overvåking og feilanalyse

Overvåking må holdes atskilt etter beskyttelsesmodell. For transport-TLS teller tilbudte og forhandlede protokoller, policyfeil, sertifikatvalidering, TLS-RPT og køalder. For S/MIME/OpenPGP teller manglende mottakernøkler, ugyldige baner eller signaturer, reserveprosedyrer, rotasjon og dekrypteringsfeil. For gatewayer kommer policyavgjørelse, Message-ID, nøkkelfingeravtrykk, klartekstbehandling og neste hopp i tillegg. For portaler er registrering, MFA/OTP, lagring, lenkeutløp, innlogging, åpning av melding og svarvei egne signaler.

En fornuftig hendelsesprotokoll besvarer:

1. Hvilken melding og hvilken mottakervei er berørt?
2. Hvilken beskyttelsesmodell og hvilken policy ble valgt?
3. Hvilken offentlig nøkkel eller hvilket sertifikat ble brukt, med hvilket fingeravtrykk og hvilken status?
4. Hvor var meldingen sist lesbar, kryptert, lagret eller satt i kø?
5. Var resultatet levering, portalarkivering, karantene, reserveprosedyre, nytt forsøk eller permanent feil?
6. Kan resultatet gjenskapes med en kontrollert testidentitet uten å eksponere produksjonsdata?

Sikkerhetskopi og gjenoppretting

Krypterte data og nøkler må planlegges sammen, men med separate beskyttelsestiltak. En sikkerhetskopi av krypterte meldinger uten de private dekrypteringsnøklene som trengs på lang sikt, kan være korrekt sikret og likevel ikke faglig gjenopprettbar. Omvendt gjør en utilstrekkelig beskyttet sikkerhetskopi av nøkkeleskrow mange enkelthemmeligheter til ett sentralt angrepspunkt. NIST behandler tillatt bruk av gjenopprettede private nøkler avhengig av nøkkeltype og kryptoperiode (NIST SP 800-57 Part 1 Rev. 5, PDF).

Minste omfang for gjenoppretting omfatter:

• krypterte originalmeldinger og eventuelt bevissikre signerte MIME-enheter;
• private dekrypteringsnøkler med metadata, passfraser, roller og godkjenningsprosedyrer;
• offentlige nøkler, sertifikatkjeder, Trust Anchors, sperre- og historiske valideringsdata;
• gateway- og portalpolicy, ruting, nøkkeltilordning, brukerdata og meldingsobjekter;
• revisjons- og tidskilder, slik at tidligere avgjørelser forblir sporbare;
• en gjenopprettingstest med gamle og nye nøkler, flere mottakere, vedlegg og signaturkontroll.

Private signaturnøkler bør ikke kopieres som en generell gjenopprettingsmekanisme. Dersom en organisasjon må signere automatisk eller på vegne av noen, er en eksplisitt organisasjonsidentitet med egen policy bedre enn en umerkelig kopi av en personlig nøkkel. Gjenopprettbarhet og ikke-benektelse står ellers i konflikt med hverandre.

Diagnoseverktøy

Feilsøkingen følger den valgte beskyttelsesmodellen. Ved transportkryptering kontrolleres DNS og TLS; ved ende-til-ende-metoder følger sertifikater, nøkler og klientbehandling; ved gatewayer kommer deres policy- og køtilstand i tillegg.

MTA-STS, TLS-RPT og DANE i DNS

Resolve-DnsName -Type TXT _mta-sts.example.ch
Resolve-DnsName -Type TXT _smtp._tls.example.ch
Resolve-DnsName -Type TLSA _25._tcp.mx.example.ch

dig +short TXT _mta-sts.example.ch
dig +short TXT _smtp._tls.example.ch
dig +dnssec TLSA _25._tcp.mx.example.ch

Resolve-DnsName og dig viser publiserte transportpolicyer. For DANE må DNSSEC-valideringsstatusen i tillegg dokumenteres; en bare synlig TLSA-tekst er ennå ikke en autentisert post.

STARTTLS og sertifikatkjede

Test-NetConnection mx.example.ch -Port 25 -InformationLevel Detailed
curl.exe --verbose --ssl-reqd smtp://mx.example.ch:25

nc -vz mx.example.ch 25
openssl s_client -starttls smtp -connect mx.example.ch:25 \
  -servername mx.example.ch -showcerts

Test-NetConnection og nc kontrollerer TCP-veien. curl og openssl s_client viser STARTTLS, handshake og kjede. Om en MTA i produksjon faller tilbake eller setter meldingen i kø ved feil, fremgår først av policyen og loggene.

S/MIME-sertifikat og bruksformål

certutil.exe -dump .\recipient-smime.cer
certutil.exe -verify -urlfetch .\recipient-smime.cer

openssl x509 -in recipient-smime.pem -noout \
  -subject -issuer -serial -fingerprint -dates -purpose -ext keyUsage -ext extendedKeyUsage
openssl verify -show_chain -CAfile trust-chain.pem recipient-smime.pem

certutil og openssl x509 viser identitet, fingeravtrykk, gyldighet og bruksformål; openssl verify kontrollerer en angitt Truststore. Testen må gjentas med de samme Trust Anchors og sperrereglene som produksjonsklienten eller gatewayen.

OpenPGP-fingeravtrykk og nøkkelstruktur

gpg.exe --show-keys --with-fingerprint --with-subkey-fingerprint .\recipient.asc
gpg.exe --list-packets .\message.pgp

gpg --show-keys --with-fingerprint --with-subkey-fingerprint recipient.asc
gpg --list-packets message.pgp

gpg viser fullstendige fingeravtrykk, undernøkler, funksjoner og pakkestruktur. --list-packets analyserer bare formatet; det bekrefter verken eier eller tillit. Fingeravtrykk må kontrolleres gjennom en autentisert sekundærkanal eller en definert organisasjonsprosedyre.

Portalvei og pakkeopptak

Invoke-WebRequest -Method Head -Uri https://securemail.example.ch/
pktmon filter remove
pktmon filter add SecureMail -p 25
pktmon start --capture --pkt-size 0 --file-name securemail.etl
pktmon stop

curl --head --verbose https://securemail.example.ch/
tcpdump -ni any -s 0 -w securemail.pcap 'tcp port 25 or tcp port 443'

Invoke-WebRequest og curl kontrollerer bare HTTP/TLS-tilgjengelighet. pktmon og tcpdump fanger bare opp ved det valgte målepunktet. Pakkedata kan inneholde SMTP-klartekst, adresser og portalmetadata og må beskyttes tilsvarende.

Teknisk historie

PEM, Privacy Enhanced Mail, standardiserte kryptografisk beskyttet Internett-e-post tidlig på 1990-tallet, men oppnådde ikke bred interoperabilitet. S/MIME koblet senere CMS-strukturen med opprinnelse i PKCS til MIME og X.509. S/MIME-standardene utviklet seg gjennom flere generasjoner frem til versjon 4.0, publisert i 2019; CMS er selv standardisert i RFC 5652 (RFC 1421, RFC 8551, RFC 5652).

OpenPGP oppstod fra PGP-pakkeformatet og ble først standardisert i RFC 2440, senere i RFC 4880. RFC 9580 erstattet RFC 4880 i 2024 og moderniserte blant annet nøkkelversjoner, fingeravtrykk og metoder for autentisert kryptering. PGP/MIME etter RFC 3156 forblir e-postkapslingen; formatutviklingen fjerner imidlertid ikke den organisatoriske oppgaven med å regulere nøkkelidentitet og gjenoppretting (RFC 9580, RFC 3156).

SMTP STARTTLS ble standardisert i RFC 2487 i 1999 og oppdatert av RFC 3207 i 2002. DANE for SMTP, MTA-STS, TLS-RPT og REQUIRETLS la senere til policy- og rapporteringslag mot nedgradering og feilkonfigurasjon. Parallelt etablerte virksomheter gatewayer og nettportaler fordi eksterne mottakere ikke pålitelig har kompatible S/MIME- eller OpenPGP-nøkler. Dermed ble e-postkryptering mindre en enkelt klientfunksjon og mer et distribuert system av SMTP, DNS, HTTPS, PKI, katalog, policy, nettidentitet og gjenoppretting (RFC 7672, RFC 8461, RFC 8460, RFC 8689).

Kilder

• NIST – SP 800-177 Rev. 1, Trustworthy Email
• IETF RFC 3207 – SMTP Service Extension for Secure SMTP over TLS
• IETF RFC 8551 – S/MIME 4.0 Message Specification
• IETF RFC 9580 – OpenPGP
• IETF RFC 5652 – Cryptographic Message Syntax
• NCCoE – DNS-Based Email Security Practice Guide
• IETF RFC 8461 – SMTP MTA Strict Transport Security
• IETF RFC 7672 – SMTP Security via DANE
• IETF RFC 8689 – SMTP REQUIRETLS
• IETF RFC 8460 – SMTP TLS Reporting
• NIST – SP 800-177 Rev. 1, PDF
• IETF RFC 5280 – Internet X.509 PKI Certificate and CRL Profile
• NIST – SP 800-57 Part 1 Rev. 5
• Microsoft Learn – S/MIME in Exchange Server
• Microsoft Learn – S/MIME in Exchange Online
• IETF RFC 3156 – MIME Security with OpenPGP
• SEPPmail – Produkter
• HIN – HIN Mail
• IETF RFC 6376 – DomainKeys Identified Mail
• HIN Support – Mail til ikke-medlemmer
• IETF RFC 5322 – Internet Message Format
• IETF RFC 6960 – Online Certificate Status Protocol
• NIST – SP 800-57 Part 1 Rev. 5, PDF
• Microsoft Learn – Resolve-DnsName
• ISC BIND 9 – dig manpage
• Microsoft Learn – Test-NetConnection
• OpenBSD – nc manpage
• curl – command line manpage
• OpenSSL – s_client
• Microsoft Learn – certutil
• OpenSSL – x509
• OpenSSL – verify
• GnuPG – gpg manual
• Microsoft Learn – Invoke-WebRequest
• Microsoft Learn – pktmon
• tcpdump – manual page
• IETF RFC 1421 – Privacy Enhancement for Internet Electronic Mail