Sta DANE-authenticatie toe voor uw mailserver of website

DANE https://datatracker.ietf.org/doc/html/rfc7671 staat voor DNS-Based Authentication of Named Entities. Met dit protocol kunnen clients het gebruikte externe certificaat controleren via TLSA DNS-records. DANE vereist DNSSEC https://datatracker.ietf.org/doc/html/rfc9364.

Dit bericht gaat niet over de implementatie aan de clientzijde, maar over de backend. Ik zal uitleggen hoe TLSA-records gemaakt kunnen worden die de openbare sleutel van het gebruikte certificaat en het gebruikte certificaat gebruiken. In principe gebruik ik alleen opensl om de TLSA-records te maken. Het artikel is gebaseerd op https://www.mailhardener.com/kb/how-to-create-a-dane-tlsa-record-with-openssl. Het meest gebruikelijke gebruik is dat mailservers zorgen voor gecodeerde e-mailoverdracht tussen MTA's, dus dat is wat ik in dit voorbeeld zal gebruiken. De mailserver die een e-mail wil afleveren bij uw beveiligde mailserver, moet nog steeds de door u gepubliceerde TLSA-records respecteren. De aanpassing voor DANE is de laatste jaren toegenomen. zelfs bedrijven als Microsoft beginnen DANE te adopteren.

Het certificaat en de ketting verkrijgen van uw mailserver

Met opensl u kunt het PEM-gecodeerde certificaat en de ketting eenvoudig opnieuw genereren vanaf een mailserver.

echo STOP | openssl s_client -connect mail.example.com:25 -starttls smtp -showcerts

Dit opent een verbinding via poort 25 met STARTTLS en drukt de certificaten af en beëindigt vervolgens de gemaakte verbinding. Om de uitvoer in een bestand op te slaan, leidt u de uitvoer gewoon om.

De certificaatketen in de uitvoer bevat waarschijnlijk meerdere certificaten die beginnen met het servercertificaat.

Laten we het eerste certificaat in de keten opslaan als server.crt, en de tweede als intermediair.crt.

Voor een mailserver zijn we geïnteresseerd in het servercertificaat (het eerste certificaat in de keten) en het issuercertificaat. We gebruiken het schema 3 1 1 (DANE EE) voor het servercertificaat en 2 1 1(DANE TA) voor het uitgevende certificaat. De in DNS gepubliceerde TLSA-waarde is een SHA256-hash van de openbare sleutel. De openbare sleutel verandert alleen als de persoonlijke sleutel die is gebruikt om de CSR van het certificaat te maken, is gewijzigd.

Maak SHA256-hash van de openbare sleutel

Uit de certificaatbestanden die we hebben verkregen, kunnen we nu de SHA256-hash berekenen.

openssl x509 -in server.crt -pubkey -noout | openssl rsa -pubin -outform der | sha256sum

genereert de public key hash voor het servercertificaat. Uitvoer kan iets soortgelijks zijn, zoals:

RSA-sleutel schrijven 4648564dc7c901037f631391d765643e8f8f86622849f59dfc9564838e1e8a76 -

We hebben hier alleen de lange string nodig. We kunnen dit herhalen voor het tussencertificaat.

Maak en publiceer TLSA DNS-records

DANE-authenticatie controleert gepubliceerde TLSA-records. Voor onze mailserver willen we de openbare sleutel SHA256-hash voor server en tussencertificaat voor poort 25 publiceren (u kunt ook records voor fort 465 of 587 publiceren als u dat wilt). Dus laten we zeggen dat we de openbare sleutel van de server voor onze mailserver (mail.example.com) willen publiceren, we publiceren het volgende record:

Naam: _25._tcp.mail.example.com.
Type: TLSA
TTL: 1 dag
Waarde: 3 1 1 4648564dc7c901037f631391d765643e8f8f86622849f59dfc9564838e1e8a76

Het is een goede gewoonte om ook een 2 1 1 TLSA-record voor het intermediate certificaat. Zorg ervoor dat u een nieuw TLSA-record publiceert wanneer uw certificaat verandert (en de privésleutel ook is gewijzigd). voor installatie van het nieuwe certificaat. U kunt meerdere instanties voor 3 1 1 xxx and 2 1 1 xxx verslagen. Nadat het nieuwe certificaat is geïnstalleerd, kunnen de verouderde records worden verwijderd.

Geef een reactie

Je e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *