MTA-STS दो अलग-अलग TLS कनेक्शन का उपयोग करता है। कोई HTTPS पॉलिसी होस्ट से पॉलिसी प्राप्त करता है; दूसरा चयनित MX को SMTP डिलीवरी की सुरक्षा करता है। एक वैध वेबसाइट प्रमाणपत्र यह स्थापित नहीं कर सकता है कि SMTP प्राप्त करना अनुपालन योग्य है, और एक वैध SMTP प्रमाणपत्र टूटे हुए नीति समापन बिंदु की मरम्मत नहीं कर सकता है।
पहले असफल समापन बिंदु का नाम बताएं
सन्दर्भ: RFC 8461 §3.3, RFC 8461 §4.1, RFC 8461 §4.2.
example.com के लिए, पॉलिसी फ़ेच mta-sts.example.com को मान्य करती है। प्रमाणपत्र में एक मेल खाने वाली DNS पहचान होनी चाहिए, जो समाप्त न हो और भेजने वाले द्वारा स्वीकार किए गए ट्रस्ट एंकर से जुड़ी हो MTA. A CNAME लक्ष्य या पुनर्निर्देशन गंतव्य इस जाँच में नीति होस्टनाम को चुपचाप प्रतिस्थापित नहीं करता है।
इसके बजाय SMTP सत्यापन चयनित MX होस्टनाम की जांच करता है। यह भी पुष्टि करें कि होस्टनाम कम से कम एक अनुमत नीति एमएक्स पैटर्न से मेल खाता है। ये अलग-अलग तुलनाएँ हैं: वाइल्डकार्ड नीति द्वारा अनुमति दिए जाने से असंबंधित प्रमाणपत्र वैध नहीं हो जाता है। चयनित नाम, प्रस्तुत श्रृंखला, सत्यापन समय और ट्रस्ट-स्टोर संदर्भ को सुरक्षित रखें।
समाप्ति से अधिक का निदान करें
सन्दर्भ: RFC 8461 §7.1, RFC 6066 §3.
विफलता एक समाप्त हो चुके पत्ते, एक होस्टनाम बेमेल, गुम या गलत मध्यवर्ती प्रमाणपत्र, एक अविश्वसनीय श्रृंखला या एक डिफ़ॉल्ट प्रमाणपत्र प्रस्तुत करने वाले समापन बिंदु से आ सकती है। HTTPS के लिए पॉलिसी होस्टनाम और SMTP के लिए MX होस्टनाम पर सेट सर्वर नाम संकेत के साथ परीक्षण करें। एक साझा होस्टिंग सेवा एसएनआई के आधार पर विभिन्न श्रृंखलाएं प्रस्तुत कर सकती है।
जहां संभव हो, प्रभावित प्रेषक के वातावरण से टिप्पणियों की तुलना करें। अलग-अलग ट्रस्ट स्टोर या पुराने क्लाइंट सॉफ़्टवेयर अलग-अलग परिणाम दे सकते हैं। एक वर्कस्टेशन पर हरा ब्राउज़र आइकन उस ब्राउज़र के लिए उपयोगी साक्ष्य है, यह कोई वादा नहीं है कि सभी भेजने वाले एमटीए एक ही श्रृंखला को स्वीकार करते हैं।
एक प्रतिलिपि प्रस्तुत करने योग्य जांच बनाए रखें
उपकरण संदर्भ: ओपनएसएसएल 3.5 एस_क्लाइंट मैनुअल. स्थापित ओपनएसएसएल 3.5.7 सहायता इन विकल्पों की पुष्टि करती है; किसी नई समापन बिंदु जांच का दावा नहीं किया गया है।
अधिकृत पॉलिसी होस्ट के लिए, प्रत्येक POLICY_HOST प्लेसहोल्डर के लिए वास्तविक पॉलिसी होस्टनाम बदलें:
ओपनएसएल एस_क्लाइंट -कनेक्ट POLICY_HOST:443 -सर्वरनाम POLICY_HOST -verify_hostname POLICY_HOST -verify_return_error -showcertsप्लेसहोल्डर को शाब्दिक रूप से न चलाएं. जरूरत पड़ने पर प्लेटफ़ॉर्म के उपयुक्त विश्वसनीय सीए स्टोर को आपूर्ति करें। stdout, stderr, OpenSSL संस्करण और सत्यापन परिणाम सहेजें। फिर मान्य HTTPS क्लाइंट के साथ सटीक पॉलिसी URL पुनर्प्राप्त करें, रीडायरेक्ट को अक्षम करके, और HTTP 200 और इच्छित पॉलिसी बॉडी की पुष्टि करें।
अधिकृत MX के लिए, प्रत्येक MX_HOST प्लेसहोल्डर के लिए वास्तविक MX होस्टनाम बदलें:
Opensl s_client -starttls smtp -कनेक्ट MX_HOST:25 -सर्वरनाम MX_HOST -verify_hostname MX_HOST -verify_return_error -showcertsदोनों जांचों पर प्रासंगिक ट्रस्ट स्टोर का उपयोग करें। सन्दर्भ: RFC 8461 §4.2 और ओपनएसएसएल होस्टनाम-जाँच शब्दार्थ. एक सफल ओपनएसएसएल होस्टनाम जांच अकेले MTA-STS अनुपालन का प्रमाण नहीं है: लागू SAN अनुपस्थित होने पर सामान्य होस्टनाम सत्यापन प्रमाणपत्र सामान्य नाम पर वापस आ सकता है। RFC 8461 §4.2 को विशेष रूप से SMTP प्रमाणपत्र में एक मिलान डीएनएस-आईडी के साथ एक विषय वैकल्पिक नाम शामिल करने की आवश्यकता होती है। प्रमाणपत्र SAN का अलग से निरीक्षण करें और पुष्टि करें कि चयनित MX होस्टनाम वहां DNS प्रविष्टि से मेल खाता है; केवल सामान्य नाम मिलान को आवश्यक SMTP पहचान जांच के रूप में स्वीकार न करें। पॉलिसी के विरुद्ध MX स्वतंत्र रूप से सत्यापित भी करें। HTTPS नीति होस्ट के लिए, RFC 8461 §3.3 केवल DNS-ID पहचानकर्ताओं के विरुद्ध मिलान की अनुमति देता है और वाइल्डकार्ड को केवल पूर्ण बाएं-सबसे लेबल के रूप में अनुमति देता है, जबकि सामान्य ओपनएसएसएल डिफ़ॉल्ट आंशिक-लेबल वाइल्डकार्ड स्वीकार कर सकते हैं; दोनों जांचों को निदान के रूप में मानें, पूर्ण MTA-STS प्रमाणपत्र-प्रोफ़ाइल सत्यापनकर्ता नहीं। परीक्षण वातावरण में एक आउटबाउंड पोर्ट-25 ब्लॉक एक कनेक्टिविटी सीमा है, यह सबूत नहीं है कि रिमोट प्रमाणपत्र टूट गया है। किसी उत्पादन समापन बिंदु की जांच नहीं की गई। नीचे दी गई 7 नवंबर 2026 प्रमाणपत्र-श्रृंखला टिप्पणियों को लूपबैक सेवाओं के विरुद्ध कैप्चर किया गया था और यहां दोबारा नहीं चलाया गया था।
पॉलिसी दावे को कमजोर किए बिना श्रृंखला की मरम्मत करें
सन्दर्भ: RFC 8461 §3.3, RFC 8461 §4.2.
इसके अनुमोदित सेवा वर्कफ़्लो के माध्यम से प्रभावित समापन बिंदु पर सही प्रमाणपत्र और मध्यवर्ती श्रृंखला स्थापित करें। मूल नाम और सभी प्रासंगिक पतों का पुनः परीक्षण करें। सफल सत्यापन परिणाम के रूप में असुरक्षित फ़ेच का उपयोग न करें या प्रमाणपत्र बेमेल को छिपाने के लिए MX पैटर्न का विस्तार न करें।
एक असफल रिफ्रेश वैध कैश्ड नीति को खारिज नहीं करता है। घटना संचार में उस अंतर को बनाए रखें: नीति को ठीक करना HTTPS भविष्य में लाने का समर्थन करता है, जबकि टूटे हुए MX ठीक करने से पुरानी नीति लागू करने वाले प्रेषकों के लिए अनुपालन डिलीवरी बहाल हो सकती है। दोनों प्रमाणपत्र जीवनचक्रों की स्वतंत्र रूप से निगरानी करें।
ऐतिहासिक साक्ष्य और शेष गुंजाइश बरकरार रखी
निम्नलिखित 7 नवंबर 2026 का प्रयोगशाला रिकॉर्ड है, जिसका निरीक्षण किया गया लेकिन इस समीक्षा के लिए नेटवर्क प्रयोग के रूप में दोबारा नहीं चलाया गया। नए ऑफ़लाइन फ़िक्स्चर निष्पादन को अलग से रिकॉर्ड किया जाता है।
टाइमस्टैम्प्ड स्थानीय ट्रेस ने HTTPS और SMTP होस्टनाम विफलताओं दोनों को पकड़ लिया। wrong.example .test प्रमाणपत्र का उपयोग करने वाला HTTPS mta-sts.example .test के लिए होस्टनाम बेमेल होने के कारण विफल हो गया। प्रमाणपत्र के साथ विफल हुआ एक समाप्त प्रमाणपत्र समाप्त हो गया है। एक नव निर्मित वैध पॉलिसी-होस्ट प्रमाणपत्र फिर HTTPS पुनर्प्राप्ति को पुनर्स्थापित करता है। अलग से, SMTP सेवा का विज्ञापन किया गया STARTTLS और पहले वैध लैब प्रमाणपत्र के साथ TLS 1.3 पूरा किया; गलत प्रमाणपत्र स्थापित होने के बाद, mx.old.example .test के लिए क्लाइंट सत्यापन विफल हो गया। सभी ट्रस्ट जांचों में एक स्पष्ट डिस्पोजेबल लैब सीए और अनुरोधित एसएनआई नाम का उपयोग किया गया। संरक्षित टाइमस्टैम्प अवलोकनों की पहचान करते हैं। वे प्रमाणपत्र ऐतिहासिक स्थिरता सामग्री हैं, न कि वर्तमान सेवा स्वास्थ्य का प्रमाण या प्रमाण। सफल HTTPS फ़ेच ईवेंट प्रमाणपत्र फ़िंगरप्रिंट भी बनाए रखते हैं; विफल HTTPS और SMTP ईवेंट सत्यापन परिणामों को बनाए रखते हैं लेकिन उनमें सहकर्मी-प्रमाणपत्र फ़िंगरप्रिंट नहीं होते हैं। इसे पृथक हैंडशेक साक्ष्य रखा गया है, यह दावा नहीं है कि किसी सार्वजनिक प्रदाता के पास प्रमाणपत्र समस्या है या सार्वजनिक प्रमाणपत्र नवीनीकरण सत्यापित किया गया था।