MQTT mTLS: X.509 İstemci Sertifikalarıyla Karşılıklı TLS Açıklaması

MQTT mTLS (karşılıklı TLS), bir bağlantının her iki tarafını da sertifikalarla doğrular: broker kimliğini cihaza kanıtlar, cihaz da kendi X.509 istemci sertifikasıyla kimliğini broker'a kanıtlar. Bu makale bunun nasıl çalıştığını açıklar, OpenSSL ile eksiksiz bir Mosquitto kurulumu gösterir ve mTLS'in işletme maliyetine değip değmediğine ya da filonuz için TLS üzerinden kullanıcı adı ve parolanın daha iyi bir tercih olup olmadığına karar vermenize yardımcı olur.

Sunucu TLS'i ve Karşılıklı TLS

Sıradan TLS üzerinden MQTT'de yalnızca broker bir sertifika sunar. İstemci bunu doğrular, tünel şifrelenir ve ardından istemci bu tünelin içinde MQTT CONNECT paketinin kullanıcı adı ve parola alanlarıyla kimlik doğrular. Çoğu bulut broker böyle çalışır ve bu, MQTT TLS yapılandırması rehberimizde ayrıntılı olarak açıklanmıştır.

Karşılıklı TLS'te broker, handshake sırasında ayrıca bir CertificateRequest gönderir. İstemci kendi sertifikasıyla yanıt verir ve handshake'in bir kısmını eşleşen özel anahtarla imzalar. Broker, istemci sertifikasının güvendiği bir CA'ya zincirlendiğini, geçerlilik süresi içinde olduğunu ve iptal edilmediğini kontrol eder. Herhangi bir kontrol başarısız olursa TCP bağlantısı, tek bir MQTT paketi bile işlenmeden kapatılır.

Ekipler Neden MQTT mTLS'i Seçer?

mTLS lehine en güçlü argüman, cihaz sırrının cihazı asla terk etmemesidir. Bir parola her bağlantıda iletilir; bu nedenle ele geçirilmiş bir broker, yanlış yapılandırılmış bir log veya bir hata ayıklama proxy'si onu yakalayabilir. Özel anahtar ise yalnızca imza üretir. Anahtar ATECC608 gibi bir secure element'te veya bir TPM'de bulunuyorsa firmware tarafından bile okunamaz; bu da bir cihazı klonlamayı çok daha zor hale getirir.

Diğer faydalar:

• Donanıma bağlı kimlik: Sertifikaları fabrikada düzenleyebilir ve sertifikanın common name'ini seri numarasına bağlayabilirsiniz.
• Erken ret: Kimliği doğrulanmamış istemciler broker MQTT'yi ayrıştırmadan önce düşürülür; bu da saldırı yüzeyini azaltır.
• Standart araçlar: X.509'u her TLS kütüphanesi, yük dengeleyici ve güvenlik ekibi anlar.

Gizli Maliyet: Sertifika Yaşam Döngüsü

mTLS, karmaşıklığı broker'ın kullanıcı veritabanından bir açık anahtar altyapısına (PKI) kaydırır. Benimsemeden önce şu görevler konusunda dürüst olun:

1. Bir CA işletin: Kök anahtarı çevrimdışı tutun, sertifika düzenlemek için bir ara CA kullanın ve ikisini de koruyun.
2. Provizyon: Her cihazda (ideal olarak cihazın kendisinde) bir anahtar üretin, bir CSR oluşturun, imzalayın ve sertifikayı yükleyin.
3. Yenileme: Sertifikaların süresi dolar. Cihazların, bir yıl rafta beklemiş olsalar bile, eskisinin süresi dolmadan yeni bir sertifika edinmenin bir yoluna ihtiyacı vardır.
4. İptal: Bir cihaz çalındığında veya kullanımdan kaldırıldığında broker onun sertifikasını kabul etmeyi bırakmalıdır. Mosquitto bir CRL dosyasını destekler; pek çok ekip bunun yerine kısa sertifika ömürlerini tercih eder.
5. CA rotasyonu: Sonunda sertifikayı düzenleyen CA'nın kendisinin de değiştirilmesi gerekir; bu da broker'a yeni bir güven çapası, her cihaza da yeni sertifikalar dağıtmak anlamına gelir.

Bunlardan herhangi birini yanlış yaparsanız filonun bir kısmında gizemli handshake hataları gibi görünen kesintiler yaşarsınız. Küçük ve orta ölçekli projelerin çoğu için, düzenli aralıklarla döndürülen ve TLS üzerinden gönderilen cihaz başına benzersiz kimlik bilgileri daha iyi bir güvenlik/emek oranı sunar. MQTT kullanıcı adı ve parola ile kimlik doğrulama ve MQTT kimlik bilgilerini döndürme rehberlerimiz bunu nasıl iyi yapacağınızı gösterir.

Mosquitto'da MQTT mTLS Kurulumu

Aşağıdaki laboratuvar kurulumu, istemci sertifikası kimlik doğrulamasını yerel olarak destekleyen Eclipse Mosquitto'yu kullanır. Kontrolünüzdeki bir makinede çalıştırın.

Adım 1: Özel Bir CA Oluşturun

mkdir -p ~/mqtt-pki && cd ~/mqtt-pki

# CA anahtarı ve kendinden imzalı CA sertifikası (10 yıl)
openssl genrsa -out ca.key 4096
openssl req -x509 -new -key ca.key -sha256 -days 3650 \
  -subj "/CN=Lab MQTT Root CA" -out ca.crt

Adım 2: Broker Sertifikasını Düzenleyin

Broker sertifikası, istemcilerin kullanacağı hostname ile eşleşen bir Subject Alternative Name'e ihtiyaç duyar.

openssl genrsa -out server.key 2048
openssl req -new -key server.key -subj "/CN=mqtt.lab.local" -out server.csr

cat > server.ext <<'EOF'
subjectAltName = DNS:mqtt.lab.local
extendedKeyUsage = serverAuth
EOF

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 825 -sha256 -extfile server.ext -out server.crt

Adım 3: Bir Cihaz Sertifikası Düzenleyin

Common name olarak cihaz ID'sini kullanın. Üretimde anahtar cihazda üretilir ve cihazdan yalnızca CSR çıkar.

openssl genrsa -out sensor-001.key 2048
openssl req -new -key sensor-001.key -subj "/CN=sensor-001" -out sensor-001.csr

cat > client.ext <<'EOF'
extendedKeyUsage = clientAuth
EOF

openssl x509 -req -in sensor-001.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 365 -sha256 -extfile client.ext -out sensor-001.crt

Adım 4: Broker'ı Yapılandırın

# /etc/mosquitto/conf.d/mtls.conf
listener 8883
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key

# Require a client certificate signed by cafile
require_certificate true

# Use the certificate CN as the MQTT username (for ACLs)
use_identity_as_username true

# Optional: reject revoked certificates
# crlfile /etc/mosquitto/certs/ca.crl

Dosyaları /etc/mosquitto/certs/ dizinine kopyalayın, anahtarı mosquitto kullanıcısının okuyabileceği hale getirin ve servisi yeniden başlatın. use_identity_as_username ile CN değeri sensor-001 kullanıcı adı olur; böylece cihaz başına ACL kuralları yazabilirsiniz.

Adım 5: İstemci Sertifikasıyla Bağlanın

mosquitto_sub -h mqtt.lab.local -p 8883 --cafile ca.crt \
  --cert sensor-001.crt --key sensor-001.key \
  -i sensor-001 -t "lab/sensor-001/#" -v

Aynı üç dosya kodda da çalışır. paho-mqtt 2.x ile Python'da:

import paho.mqtt.client as mqtt

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="sensor-001")
client.tls_set(ca_certs="ca.crt", certfile="sensor-001.crt", keyfile="sensor-001.key")
client.connect("mqtt.lab.local", 8883)
client.publish("lab/sensor-001/temp", "21.4", qos=1)
client.loop(2)
client.disconnect()

--cert ve --key olmadan bağlanırsanız handshake hemen başarısız olur; bu, require_certificate ayarının etkin olduğunu doğrulamanın hızlı bir yoludur. Bunun gibi laboratuvar kurulumları kendinden imzalı bir kök kullanır; MQTT için kendinden imzalı sertifikalar rehberimiz tuzakları ele alır.

Yaygın mTLS Hataları

• Broker'dan "certificate required" veya handshake alert'i: İstemci sertifika göndermedi. Sertifika ve anahtar yollarını kontrol edin.
• "unknown ca": İstemci sertifikası, broker'ın cafile dosyasında bulunmayan bir CA tarafından imzalanmış.
• "unsupported certificate purpose": Sertifikada clientAuth extended key usage eksik.
• Anahtar uyuşmazlığı: Anahtar dosyası sertifikaya ait değil. openssl x509 -noout -modulus -in sensor-001.crt | openssl md5 çıktısını anahtar üzerinde çalıştırılan aynı komutla karşılaştırın.
• Süresi dolmuş sertifika: Tarihleri openssl x509 -noout -dates -in sensor-001.crt ile kontrol edin ve cihazın saatini de kontrol edin.

mTLS Ne Zaman Kullanılmalı, Kimlik Bilgileri Ne Zaman Yeterli?

mTLS; broker'ı kontrol ettiğinizde, donanım destekli kimliğe ihtiyaç duyduğunuzda, sertifika tabanlı cihaz kimliğini zorunlu kılan düzenlenmiş bir ortamda çalıştığınızda veya zaten bir PKI işlettiğinizde iyi bir seçimdir. Prototipler, küçük filolar ve sertifika yenilemeyi üstlenecek kimsesi olmayan ekipler için genellikle gereğinden fazladır.

ConnectMQ, TLS üzerinden kimlik bilgileri yaklaşımını benimser: broker herkesçe güvenilen bir Let's Encrypt sertifikası sunar ve her istemci portalda oluşturulan bir kullanıcı adı, parola ve client ID ile kimlik doğrular. Client ID'ler verilen kimlik bilgilerine bağlıdır ve tekrarlanan başarısız oturum açma denemeleri IP engellemeye yol açar. ConnectMQ istemci sertifikası kimlik doğrulaması sunmaz; bu nedenle mTLS kesin bir gereksinimse yukarıda gösterilen Mosquitto gibi kendi yapılandırdığınız bir broker'a ihtiyacınız olur. Yine de projelerin büyük çoğunluğu için güçlü, cihaz başına kimlik bilgilerine sahip tam yönetilen bir MQTT hizmeti, mTLS'in eklediğinden çok daha fazla operasyonel riski ortadan kaldırır. Genel tablo MQTT güvenliği en iyi uygulamaları yazımızda ele alınır.

ConnectMQ ile Başlayın

TLS üzerinden kimlik bilgileri tehdit modelinize uyuyorsa ConnectMQ, hiçbir PKI işletmeden güvenli bir broker sunar. app.connectmq.com adresinden kaydolun, kredi kartı gerektirmeyen ücretsiz Serverless planı seçin, bir broker oluşturun ve oluşturulan kimlik bilgileriyle 8883 portundan bağlanın. Önce broker.connectmq.com adresindeki herkese açık MQTT test broker'ında prototip oluşturabilir, canlıya geçtiğinizde özel kimlik bilgilerine geçebilirsiniz.

Sık Sorulan Sorular

mTLS, TLS üzerinden kullanıcı adı ve paroladan daha mı güvenli?

Paylaşılan sırrı ağdan kaldırır ve donanımsal anahtar depolamayla iyi eşleşir; bu nedenle kimlik bilgisi hırsızlığına karşı daha dayanıklıdır. Bunun bedeli, güvenilir biçimde işletmeniz gereken bir sertifika yaşam döngüsüdür.

mTLS'i ve kullanıcı adı ile parolayı birlikte kullanabilir miyim?

Evet. Örneğin Mosquitto, bir istemci sertifikası isteyip yine de MQTT kullanıcı adını ve parolasını kontrol edebilir; bu da iki bağımsız faktör sağlar.

ConnectMQ istemci sertifikası kimlik doğrulamasını destekliyor mu?

Hayır. ConnectMQ, istemcileri TLS üzerinden gönderilen oluşturulmuş bir kullanıcı adı, parola ve client ID ile doğrular. Özellikle mTLS'e ihtiyacınız varsa kendi yönettiğiniz bir broker kullanın.

Cihaz sertifikaları ne kadar süre geçerli olmalı?

Tek bir cevabı yoktur. Daha kısa ömürler iptale bağımlılığı azaltır ancak güvenilir otomatik yenileme gerektirir; yenileme sürecinizin sahadaki cihazlarda süre dolması riski olmadan kaldırabileceği en kısa süreyi seçin.