यह गाइड आपको दिखाती है Skype for Business Server पर CSR (Certificate Signing Request) कैसे जनरेट करें। आप इस रिक्वेस्ट को दो तरीकों से बना सकते हैं: Skype for Business Server Deployment Wizard के अंदर मौजूद ग्राफिकल Certificate Wizard से, या Skype for Business Server Management Shell में Request-CsCertificate cmdlet से। दोनों ही सर्टिफिकेट के लिए नाम आपकी पब्लिश की गई topology से पढ़ते हैं, यही वजह है कि ये किसी सामान्य CSR टूल की तुलना में यहाँ अधिक विश्वसनीय हैं।
ये चरण Skype for Business Server (on-premises): 2015, 2019 और Subscription Edition पर लागू होते हैं। ये Skype for Business Online पर लागू नहीं होते, जो 31 जुलाई, 2021 को बंद हो गया था, या उपभोक्ता Skype पर, जो 5 मई, 2025 को बंद हो गया। यदि आपका संगठन पहले ही Microsoft Teams पर स्थानांतरित हो चुका है, तो Microsoft उस सेवा के लिए सर्टिफिकेट खुद प्रबंधित करता है और आपको कोई CSR जनरेट करने की आवश्यकता नहीं है।
पहले अपने Skype for Business Server के वर्जन की जांच करें
Skype for Business Server Management Shell खोलें और हर इंस्टॉल किए गए कंपोनेंट का बिल्ड सूचीबद्ध करें:
Get-CsServerPatchVersion
संबंधित Get-CsServerVersion cmdlet केवल लोकल सर्वर की लाइसेंसिंग और बेस बिल्ड की जानकारी देता है, cumulative update के बिना, इसलिए जब आपको यह जानना हो कि आप ठीक-ठीक किस अपडेट स्तर पर हैं तो Get-CsServerPatchVersion का उपयोग करें।
जुलाई 2026 तक का सपोर्ट स्टेटस:
- Skype for Business Server 2015 और 2019 दोनों का extended support 14 अक्टूबर, 2025 को समाप्त हो गया।
- पेड Extended Security Update प्रोग्राम अक्टूबर 2025 से अप्रैल 2026 के अंत तक (Period 1) चला। दूसरी विंडो, Period 2, मई 2026 से अक्टूबर 2026 के अंत तक चलती है। Period 2 को अलग से खरीदना पड़ता है: Period 1 खरीदने पर यह अपने आप आगे नहीं बढ़ता, और Period 2 खरीदने के लिए आपको Period 1 खरीदना जरूरी नहीं है।
- Microsoft ने 21 जुलाई, 2026 को फिर से पुष्टि की कि आगे कोई और विस्तार नहीं दिया जाएगा। अक्टूबर 2026 समाप्त होने के बाद 2015 या 2019 के लिए कोई और अपडेट नहीं मिलेगा, यहां तक कि Period 2 ESU रखने वाले संगठनों के लिए भी नहीं।
- Skype for Business Server Subscription Edition 1 जुलाई, 2025 को शुरू हुआ, यह Microsoft Modern Lifecycle Policy का पालन करता है और यह वर्तमान on-premises रिलीज है। इसे Skype for Business Server 2019 के in-place upgrade के रूप में इंस्टॉल किया जाता है।
CSR प्रक्रिया तीनों में समान है। सपोर्ट स्टेटस से यह नहीं बदलता कि सर्टिफिकेट कैसे व्यवहार करता है: एक एक्सपायर्ड सर्टिफिकेट क्लाइंट साइन-इन, मीटिंग जॉइन और सर्वर-टू-सर्वर TLS को तोड़ देता है चाहे आप कोई भी रिलीज चला रहे हों, इसलिए अपने माइग्रेशन की योजना बनाते समय रिन्यू करते रहें।
CSR जनरेट करने से पहले
- पहले अपनी topology पब्लिश करें। दोनों तरीके subject name और subject alternative names उस topology डॉक्यूमेंट से पढ़ते हैं जिसे Topology Builder ने Central Management store में पब्लिश किया है। wizard इन्हें एक read-only सारांश पेज पर दिखाता है। यदि वहाँ कोई नाम गलत है, तो wizard को कैंसिल करें, इसे Topology Builder में ठीक करें, दोबारा पब्लिश करें, और फिर से रिक्वेस्ट शुरू करें।
- पहले DNS रिकॉर्ड बनाएं। सर्टिफिकेट पर आने वाला हर नाम उन क्लाइंट्स के लिए resolve होना चाहिए जो इसका उपयोग करेंगे।
- अपनी अनुमतियाँ जांचें। Certificate Wizard चलाने के लिए आपको RTCUniversalServerAdmins का सदस्य होना जरूरी है। Microsoft कहता है कि किसी सार्वजनिक CA को ऑफलाइन रिक्वेस्ट भेजने के लिए इस एक ग्रुप की सदस्यता के अलावा किसी अन्य ग्रुप मेंबरशिप की जरूरत नहीं है, लेकिन बाद में CA के रिस्पॉन्स को प्रोसेस करने और सर्टिफिकेट असाइन करने के लिए स्थानीय Administrators ग्रुप की भी जरूरत होती है। किसी internal Windows CA से ऑनलाइन रिक्वेस्ट करने के लिए स्थानीय Administrators के साथ-साथ उस डोमेन में एक authenticated domain account चाहिए जो CA को होस्ट करता है।
- तय करें कि आप कौन सा सर्टिफिकेट रिक्वेस्ट कर रहे हैं। एक Front End या Standard Edition सर्वर में एक Default सर्टिफिकेट होता है साथ ही internal और external web services सर्टिफिकेट्स। एक Edge Server में अलग external सर्टिफिकेट और internal सर्टिफिकेट होते हैं। ये आपस में इंटरचेंजेबल नहीं हैं।
कौन-से Skype for Business सर्टिफिकेट को कोई पब्लिक CA साइन कर सकता है?
सभी नहीं, और यही वह बिंदु है जिस पर अधिकतर लोग गलती कर बैठते हैं। नवंबर 2015 से CA/Browser Forum की Baseline Requirements ने publicly trusted CAs को internal server names और reserved IP addresses के लिए सर्टिफिकेट जारी करने से प्रतिबंधित कर दिया है। .local पर खत्म होने वाला कोई भी नाम, कोई भी single-label host name और किसी ऐसे डोमेन का FQDN जिसे आप सार्वजनिक रूप से नहीं रखते, पब्लिक सर्टिफिकेट पर नहीं जा सकता।
- पब्लिक CA से: external Edge सर्टिफिकेट और reverse proxy सर्टिफिकेट। Microsoft का दिशानिर्देश है कि external Edge इंटरफेस को कम-से-कम किसी पब्लिक CA का सर्टिफिकेट चाहिए, क्योंकि external क्लाइंट्स और federated partners को इस पर भरोसा करना होता है।
- आमतौर पर आपके internal CA से: Default सर्टिफिकेट, internal web services सर्टिफिकेट, Director सर्टिफिकेट और internal Edge सर्टिफिकेट। ये pool और server FQDNs को वहन करते हैं जो अक्सर internal नाम होते हैं। यदि आपके internal FQDNs किसी ऐसे डोमेन में आते हैं जिसका सार्वजनिक स्वामित्व आपके पास है, तो आप इनके लिए भी पब्लिक सर्टिफिकेट खरीद सकते हैं। Microsoft स्पष्ट रूप से internal Edge सर्टिफिकेट को पब्लिक CA या आपके internal CA दोनों में से किसी से भी लेने की अनुमति देता है।
क्योंकि external सर्टिफिकेट एक साथ कई नाम वहन करता है, यह सामान्यतः एक मल्टी-डोमेन (UCC/SAN) सर्टिफिकेट होता है। Microsoft simple URL नामों और autodiscover नामों के लिए wildcard एंट्रियों को समर्थित के रूप में दस्तावेज करता है, लेकिन दस्तावेजित Edge सर्टिफिकेट प्रत्येक SIP access name को स्पष्ट रूप से सूचीबद्ध करता है, इसलिए किसी wildcard पर निर्भर रहने के बजाय हर SIP डोमेन के लिए अलग sip.yourdomain.tld एंट्री सूचीबद्ध करें।
subject name और SAN एंट्रियों की योजना बनाएं
Skype for Business सर्टिफिकेट SAN-heavy होते हैं, और ब्राउज़र तथा क्लाइंट hostname को Common Name के बजाय SAN फ़ील्ड से मैच करते हैं। ऑर्डर करने से पहले इस सूची को सही करना ही एक सर्टिफिकेट और एक reissue के बीच का अंतर तय करता है। तालिका Microsoft के अपने उदाहरण डोमेन का उपयोग करती है: contoso.com प्राइमरी SIP डोमेन के रूप में, fabrikam.com दूसरे SIP डोमेन के रूप में और contoso.net internal डोमेन के रूप में।
| सर्टिफिकेट | Subject name (CN) | Subject alternative names | उदाहरण |
|---|---|---|---|
| Default (Standard Edition या Front End pool) | Pool FQDN | Pool FQDN और server FQDN। यदि यह pool auto-logon सर्वर है और strict DNS matching group policy में लागू है तो हर SIP डोमेन के लिए sip.sipdomain जोड़ें। | SN=eepool.contoso.com; SAN=eepool.contoso.com; SAN=ee01.contoso.com |
| Web internal | Pool FQDN (Standard Edition पर server FQDN) | Internal web FQDN, server FQDN, pool FQDN, हर SIP डोमेन के लिए Meet simple URL, Dial-in simple URL और Admin simple URL | SN=eepool.contoso.com; SAN=eepool.contoso.com; SAN=ee01.contoso.com; SAN=meet.contoso.com; SAN=meet.fabrikam.com; SAN=dialin.contoso.com; SAN=admin.contoso.com |
| Web external | Pool FQDN (Standard Edition पर server FQDN) | External web FQDN, हर SIP डोमेन के लिए Meet simple URL, और Dial-in simple URL | SN=eepool.contoso.com; SAN=webcon01.contoso.com; SAN=meet.contoso.com; SAN=meet.fabrikam.com; SAN=dialin.contoso.com |
| Mobility (Front End और Director सर्टिफिकेट्स में जोड़ा गया) | ऊपर जैसा | internal autodiscover नाम और external autodiscover नाम, प्रति SIP डोमेन एक जोड़ी | SAN=lyncdiscoverinternal.contoso.com; SAN=lyncdiscover.contoso.com |
| External Edge | आपके primary SIP डोमेन का sip नाम | प्रति SIP डोमेन एक sip एंट्री साथ ही web conferencing Edge FQDN | SN=sip.contoso.com; SAN=sip.contoso.com; SAN=webcon.contoso.com; SAN=sip.fabrikam.com |
| Internal Edge | Edge internal FQDN | कोई नहीं। internal Edge सर्टिफिकेट केवल एक subject name का उपयोग करता है। | SN=sfbedge.contoso.net |
| Reverse proxy | External web services FQDN | external autodiscover नाम साथ ही आपके external web services FQDNs | SAN=lyncdiscover.contoso.com; SAN=skypewebextpool01.contoso.com; SAN=dirwebexternal.contoso.com |
सबमिट करने से पहले चार बातें जांचने योग्य हैं:
- Simple URLs। आपको प्रति SIP डोमेन एक Meet simple URL चाहिए, पूरे संगठन के लिए एक Dial-in simple URL, और Admin simple URL वैकल्पिक है। आपके द्वारा इस्तेमाल किया जाने वाला हर Meet URL सर्टिफिकेट पर होना चाहिए।
- sipinternal और sipexternal। यदि आपने DNS में sipinternal.contoso.com या sipexternal.contoso.com रिकॉर्ड बनाए हैं, तो Microsoft इन्हें भी SAN सूची में शामिल करने की आवश्यकता रखता है।
- A/V नाम SAN नहीं है। av.contoso.com A/V Edge सेवा के लिए एक DNS रिकॉर्ड है, जो मीडिया को एन्क्रिप्ट करने के लिए किसी सर्टिफिकेट का उपयोग नहीं करता, इसलिए यह रिक्वेस्ट में शामिल नहीं होता। external Edge सर्टिफिकेट Access Edge, Web Conferencing Edge और अलग A/V Authentication सेवा को असाइन किया जाता है।
- Edge pools एक ही सर्टिफिकेट साझा करते हैं। किसी pool के हर Edge Server को media relay authentication सेवा के लिए बिल्कुल वही सर्टिफिकेट और वही private key वहन करना जरूरी है, इसलिए यही वह एक रिक्वेस्ट है जहाँ आपको वाकई एक exportable private key की जरूरत है।
Deployment Wizard से CSR जनरेट करें
यदि आपने पहले ही किसी अन्य टूल से अपना CSR जनरेट कर लिया है, तो इसे छोड़ें और इसके बजाय Skype for Business Server पर SSL सर्टिफिकेट कैसे इंस्टॉल करें संबंधी हमारी गाइड फॉलो करें।
ये चरण उसी सर्वर पर चलाएं जिसके लिए सर्टिफिकेट है: Default या web services सर्टिफिकेट के लिए Front End Server, Edge सर्टिफिकेट के लिए Edge Server।
- Start खोलें और Skype for Business Server Deployment Wizard लॉन्च करें।
- Install or Update Skype for Business Server System पर क्लिक करें।
- Step 3: Request, Install or Assign Certificates के बगल में, Run पर क्लिक करें। यदि इस कंप्यूटर पर पहले से सर्टिफिकेट मौजूद हैं तो यह Run Again दिखाता है।
- Certificate Wizard में, आपको जिस सर्टिफिकेट की जरूरत है उसे चुनें (उदाहरण के लिए Default certificate, या Edge Server पर External Edge certificate) और Request पर क्लिक करें।
- Prepare the request now, but send it later (offline certificate request) चुनें। यही पब्लिक CA के लिए विकल्प है। दूसरा विकल्प, Send the request immediately to an online certification authority, आपके अपने PKI के अंदर मौजूद किसी CA के साथ enroll करता है, सामान्यतः एक internal Windows CA, और यह पब्लिक CA का रास्ता नहीं है।
- File Name बॉक्स में रिक्वेस्ट के लिए पथ और फ़ाइल नाम टाइप करें, या कोई स्थान चुनने के लिए Browse पर क्लिक करें। ध्यान रखें कि आपने इसे कहाँ सेव किया है। डिफ़ॉल्ट रूप से यह wizard चलाने वाले खाते के Documents फ़ोल्डर में होता है।
- Name and Security Settings पेज पर, एक Friendly Name टाइप करें जो कंप्यूटर के सर्टिफिकेट स्टोर में यूनीक हो, फिर Bit length चुनें। सूची 1024, 2048 और 4096 प्रदान करती है: 2048 चुनें, क्योंकि कोई भी पब्लिक CA 1024-बिट की को साइन नहीं करेगा। जब तक आप किसी Edge Server pool के लिए सर्टिफिकेट रिक्वेस्ट नहीं कर रहे हैं तब तक Mark the certificate’s private key as exportable को खाली छोड़ दें, यही वह स्थिति है जिसे Microsoft इसे आवश्यक बताता है।
- Organization Information पेज पर Organization और Organizational Unit भरें। सर्टिफिकेट पर OU फ्री टेक्स्ट होता है और इसका किसी Active Directory organizational unit से मेल खाना जरूरी नहीं है।
- Geographical Information पेज पर Country चुनें, फिर State/Province और City/Locality टाइप करें। दोनों को पूरा लिखें, जैसे AZ के बजाय Arizona।
- Subject Name / Subject Alternative Names पेज की समीक्षा करें। ये एंट्रियाँ आपकी पब्लिश की गई topology से आती हैं और यहां संपादित नहीं की जा सकतीं। यदि कोई गलत है, तो Cancel पर क्लिक करें, इसे Topology Builder में ठीक करें, topology को दोबारा पब्लिश करें, और फिर से रिक्वेस्ट शुरू करें।
- SIP Domain setting on Subject Alternate Names (SANs) पेज पर, अपने primary SIP डोमेन और किसी अन्य SIP डोमेन को टिक करें जिसे यह सर्टिफिकेट कवर करना चाहिए। यदि आप किसी को टिक नहीं करते और आपका कॉन्फ़िगरेशन बाद में बदलता है, तो आपको नया सर्टिफिकेट रिक्वेस्ट करना होगा।
- Configure Additional Subject Alternate Names पेज पर, कोई भी ऐसा नाम जोड़ें जो topology ने नहीं दिया: FQDN टाइप करें और Add पर क्लिक करें। Remove और Clear All केवल उन एंट्रियों को प्रभावित करते हैं जो आपने इस पेज पर जोड़ी हैं, topology से आने वाले नामों को नहीं।
- रिक्वेस्ट सारांश जांचें और CSR जनरेट करने के लिए Next पर क्लिक करें। Certificate Request File पेज पर, रिक्वेस्ट को Notepad में खोलने के लिए View पर क्लिक करें ताकि आप इसे कॉपी कर सकें, फिर Finish पर क्लिक करें।
PowerShell से CSR जनरेट करें
Skype for Business Server Management Shell को administrator के रूप में खोलें और Request-CsCertificate चलाएं। यह वही रिक्वेस्ट बनाता है जो wizard बनाता है: cmdlet फाइल लिखने से पहले आपकी topology का विश्लेषण करता है, और subject name व subject alternative names अपने आप भर देता है।
एक Front End Server के लिए एक पूर्ण ऑफलाइन रिक्वेस्ट कुछ इस तरह दिखती है। यह एक ही लाइन है, इसलिए पूरी चीज़ कॉपी करें:
Request-CsCertificate -New -Type Default,WebServicesInternal,WebServicesExternal -ComputerFqdn "ee01.contoso.com" -FriendlyName "SfB Front End 2026" -KeySize 2048 -Organization "Contoso Ltd" -OU "IT" -Country US -State "Arizona" -City "Phoenix" -DomainName "meet.contoso.com,dialin.contoso.com,admin.contoso.com,lyncdiscover.contoso.com" -Output "C:certscontoso_sfb.csr"
हर भाग क्या करता है:
-Newएक नई रिक्वेस्ट शुरू करता है और कमांड के इस रूप के लिए आवश्यक है।-Typeअनिवार्य है। यह उन service roles के नाम बताता है जिन्हें सर्टिफिकेट कवर करता है, और वे roles तय करते हैं कि cmdlet SAN फ़ील्ड में कौन-से FQDNs डालता है।-Outputआपके दिए गए पथ पर एक ऑफलाइन रिक्वेस्ट लिखता है। यही वह चीज़ है जो कमांड को एक ऐसा CSR बनाने में सक्षम बनाती है जिसे आप किसी पब्लिक CA को भेज सकते हैं। इसे छोड़ दें और इसके बजाय-CAजोड़ें, तो cmdlet सीधे किसी internal Windows CA से संपर्क करता है।-ComputerFqdnउस कंप्यूटर का FQDN है जिसके लिए सर्टिफिकेट है। Microsoft का दिशानिर्देश है कि हमेशा कंप्यूटर नाम का उपयोग करें, तब भी जब आप pool सर्टिफिकेट रिक्वेस्ट कर रहे हों, क्योंकि cmdlet खुद ही subject में pool नाम जोड़ देता है।-DomainNameउन अतिरिक्त FQDNs की एक कॉमा-अलग सूची लेता है जिन्हें topology द्वारा दिए गए नामों के अलावा SAN फ़ील्ड में जोड़ना है।-Organization,-OU,-Country,-Stateऔर-Citysubject को भरते हैं। Country दो-अक्षर का कोड लेता है (US, GB, DE); state और city को पूरा लिखें।-KeySize1024, 2048 और 4096 स्वीकार करता है। 2048 या उससे बड़ा उपयोग करें।-FriendlyNameWindows स्टोर में सर्टिफिकेट को लेबल करता है, और उस स्टोर में यूनीक होना जरूरी है।-PrivateKeyExportable $Trueकी को exportable के रूप में चिह्नित करता है। इसे तभी सेट करें जब आपको वाकई सर्टिफिकेट को किसी दूसरी मशीन पर कॉपी करने की जरूरत हो, जैसे नीचे दिया गया Edge pool मामला।-AllSipDomainहर SIP डोमेन को SAN फ़ील्ड में जोड़ता है। इसके बिना केवल primary SIP डोमेन अपने आप शामिल होता है।-Templateकिसी internal CA पर एक certificate template का नाम बताता है। पब्लिक CA रिक्वेस्ट के लिए इसका कोई अर्थ नहीं है।
वे सर्टिफिकेट प्रकार जिन्हें आप -Type में पास कर सकते हैं
Microsoft इन मानों का दस्तावेजीकरण करता है, और नोट करता है कि यह सूची पूरी नहीं है: AccessEdgeExternal, AudioVideoAuthentication, DataEdgeExternal, Default, External, Internal, iPhoneAPNService, iPadAPNService, MPNService, PICWebService, ProvisionService, WebServicesExternal, WebServicesInternal और WsFedTokenTransfer। कई प्रकारों को कॉमा से अलग करें।
इनमें से दो on-premises सर्वर पर बेकार हैं: Microsoft PICWebService और ProvisionService को Skype for Business Online के प्रकार बताता है, और वह सेवा 2021 में बंद हो गई थी। व्यवहार में आप इन तीन संयोजनों में से एक का उपयोग करेंगे:
- Front End या Director:
-Type Default,WebServicesInternal,WebServicesExternal - Edge internal interface:
-Type Internal - Edge external interfaces:
-Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication
external Edge रिक्वेस्ट वही है जिसे exportable की चाहिए, क्योंकि pool में हर Edge Server को समान सर्टिफिकेट और की साझा करनी होती है:
Request-CsCertificate -New -Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication -ComputerFqdn "sfbedge01.contoso.net" -FriendlyName "SfB Edge External 2026" -KeySize 2048 -PrivateKeyExportable $True -Organization "Contoso Ltd" -OU "IT" -Country US -State "Arizona" -City "Phoenix" -DomainName "sip.contoso.com,webcon.contoso.com,sip.fabrikam.com" -Output "C:certscontoso_edge.csr"
key algorithm के रूप में RSA रखें
cmdlet में एक -KeyAlg पैरामीटर भी है जो RSA, ECDH_P256, ECDH_P384 और ECDH_P521 स्वीकार करता है। Microsoft की अपनी system requirements बताती हैं कि Skype for Business Server CNG सर्टिफिकेट्स को सपोर्ट नहीं करता, और इस वर्कफ़्लो में पब्लिक CAs RSA की अपेक्षा करते हैं, इसलिए -KeyAlg को छेड़ें नहीं और रिक्वेस्ट को RSA का उपयोग करने दें। वही दस्तावेज़ RSASSA-PSS सिग्नेचर एल्गोरिथ्म को भी खारिज करता है, जिसके बारे में यह कहता है कि यह साइन-इन और कॉल फ़ॉरवर्डिंग विफलताओं का कारण बन सकता है।
पहले से बनाई गई रिक्वेस्ट को प्रबंधित करना
यही cmdlet अपनी pending रिक्वेस्ट को खुद ट्रैक करता है। उन्हें सूचीबद्ध करें, जारी हो चुकी किसी रिक्वेस्ट को प्राप्त करें, या किसी को उसके request ID से हटाएं:
Request-CsCertificate -List
Request-CsCertificate -Retrieve
Request-CsCertificate -Clear -RequestId 224
जब कोई revoked रिक्वेस्ट रास्ते में होने के कारण retrieval विफल हो जाता है, तो रिक्वेस्ट को clear करना भी दस्तावेजित समाधान है: Request-CsCertificate केवल Issued, Denied और Pending स्थितियों को संभालता है।
अपने Certificate Authority को CSR सबमिट करें
आपने जो फ़ाइल सेव की है उसे किसी plain text editor में खोलें। wizard का View बटन इसे आपके लिए Notepad में खोलता है। हर चीज़ कॉपी करें, header और footer लाइनों सहित। Windows सामान्यतः इन्हें इस तरह लिखता है:
-----BEGIN NEW CERTIFICATE REQUEST-----
MIICtjCCAZ4CAQAwcTELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0FyaXpvbmExEDAO
... many more lines of base64 ...
jCD4RG92Kab0LzO1Hl07fPvTf8j4kDkWhlE=
-----END NEW CERTIFICATE REQUEST-----
कुछ टूल शब्द NEW के बिना BEGIN CERTIFICATE REQUEST लिखते हैं। दोनों ही एक ही PKCS #10 रिक्वेस्ट हैं और Certificate Authorities दोनों को स्वीकार करते हैं। ध्यान दें कि ये मार्कर हर तरफ पांच सामान्य हाइफ़न होते हैं। यदि कोई वर्ड प्रोसेसर या rich-text फ़ील्ड इन्हें typographic dashes में बदल दे, या कोई line break हटा दे, तो CA रिक्वेस्ट को malformed मानकर अस्वीकार कर देगा, इसलिए किसी plain text फ़ील्ड में पेस्ट करें।
validation के लिए भुगतान करने से पहले, हमारे CSR Decoder के जरिए इस ब्लॉक को चलाएं और पुष्टि करें कि आपकी योजना तालिका का हर नाम वाकई SAN सूची में मौजूद है। कोई गायब Meet URL या भूला हुआ दूसरा SIP डोमेन का मतलब है एक reissue।
सर्टिफिकेट का इंतज़ार करते समय दो बातों से बचें:
- pending रिक्वेस्ट को clear न करें या सर्वर को दोबारा न बनाएं। private key उस सर्वर के सर्टिफिकेट स्टोर में रहती है और कभी वहां से बाहर नहीं जाती। बिना मैचिंग key के जारी किया गया सर्टिफिकेट बेकार है।
- एक ही सर्टिफिकेट के लिए दूसरा CSR रिक्वेस्ट न करें और दोनों सबमिट न करें। हर रिक्वेस्ट अपनी खुद की key pair बनाता है, और CA जो सर्टिफिकेट लौटाता है वह केवल इनमें से एक के साथ ही मैच करेगा।
अभी से रिन्यूअल की तारीख की योजना बना लें। 15 मार्च, 2026 से publicly trusted TLS सर्टिफिकेट 200 दिनों तक सीमित हैं, जो 15 मार्च, 2027 को 100 दिनों में और 15 मार्च, 2029 को 47 दिनों में घट जाएंगे। Skype for Business पर अब एक manual wizard-driven रिन्यूअल कम से कम साल में दो बार आता है, इसलिए topology नोट्स के साथ इसे कैलेंडर में डालें।
यदि आप सर्वर पर बिल्कुल भी रिक्वेस्ट जनरेट नहीं करना चाहते, तो हमारा CSR Generator आपके ब्राउज़र में एक CSR और एक private key बनाता है। Skype for Business पर यह कमजोर विकल्प है, क्योंकि रिक्वेस्ट आपकी topology से नाम नहीं उठाएगी और फिर आपको जारी सर्टिफिकेट को .pfx फ़ाइल में बदलना होगा और key को मैनुअल तरीके से इंपोर्ट करना होगा।
CA द्वारा आपका सर्टिफिकेट जारी करने के बाद
validation पूरा होने पर CA सर्टिफिकेट लौटा देता है। इसे उसी सर्वर पर इंपोर्ट करें, फिर इसे उन service roles को असाइन करें जिनके लिए आपने इसे रिक्वेस्ट किया था, या तो Deployment Wizard के Step 3 में वापस जाकर या Import-CsCertificate और Set-CsCertificate cmdlets से। हमारी साथी गाइड Skype for Business Server पर SSL सर्टिफिकेट कैसे इंस्टॉल करें दोनों को विस्तार से बताती है।
क्योंकि आपने इस सर्वर पर रिक्वेस्ट जनरेट की थी, private key पहले से ही इसके सर्टिफिकेट स्टोर में है, इसलिए CA जो लौटाता है वह अकेले सर्टिफिकेट ही है। इसे जैसा दिया गया है वैसे ही इंपोर्ट करें: एक .cer या .crt फ़ाइल, या कई CAs द्वारा Windows के लिए दिया जाने वाला .p7b बंडल। कुछ भी बदलने की जरूरत नहीं है। आपको केवल तब PKCS#12 फ़ाइल (.pfx या .p12) चाहिए जब सर्टिफिकेट और उसकी private key को साथ यात्रा करनी हो, जो तब होता है जब आपने CSR किसी अलग मशीन पर बनाया हो। पहले इन्हें OpenSSL से मिलाएं, फिर .pfx को उसके पासवर्ड के साथ इंपोर्ट करें:
openssl pkcs12 -export -out cert.pfx -inkey private.key -in cert.crt -certfile chain.crt
सर्टिफिकेट असाइन होने और सेवाओं के रिस्टार्ट हो जाने के बाद, यह पुष्टि करने के लिए कि chain और SAN सूची वैसी ही है जैसी आप चाहते थे, हमारे SSL Checker से external नाम को स्कैन करें।
अक्सर पूछे जाने वाले प्रश्न
किसी Front End Server या Director के लिए, -Type Default,WebServicesInternal,WebServicesExternal उपयोग करें। किसी Edge Server के internal interface के लिए, -Type Internal उपयोग करें। external Edge इंटरफेस के लिए, -Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication उपयोग करें। आपके द्वारा चुना गया प्रकार तय करता है कि cmdlet आपकी topology से कौन-से FQDNs पढ़ता है और उन्हें SAN फ़ील्ड में लिखता है, इसलिए यह कोई सजावटी सेटिंग नहीं है।
केवल तभी जब नाम सार्वजनिक रूप से पंजीकृत हों। नवंबर 2015 से, publicly trusted CAs internal server names या reserved IP addresses वाले सर्टिफिकेट जारी नहीं कर सकते, जो .local डोमेन और single-label host names को अपवर्जित करता है। किसी ऐसे डोमेन का FQDN जिसका स्वामित्व आपके पास नहीं है वह भी अलग से वर्जित है, क्योंकि CA आपके नियंत्रण को सत्यापित नहीं कर सकता। एक सामान्य deployment में, external Edge सर्टिफिकेट और reverse proxy सर्टिफिकेट एक पब्लिक CA से आते हैं, जबकि Default, internal web services, Director और internal Edge सर्टिफिकेट आपके संगठन के अपने CA से आते हैं।
क्योंकि वे wizard द्वारा संपादित करने के लिए नहीं हैं। Subject Name / Subject Alternative Names पेज उन नामों का read-only सारांश है जो उस topology डॉक्यूमेंट में परिभाषित हैं जिसे Topology Builder ने Central Management store में पब्लिश किया है। यदि कोई एंट्री गलत है, तो wizard को कैंसिल करें, Topology Builder में deployment को ठीक करें, दोबारा पब्लिश करें, और सर्टिफिकेट को फिर से रिक्वेस्ट करें। आप बाद में flow में, Configure Additional Subject Alternate Names पेज पर, अतिरिक्त नाम जोड़ सकते हैं।
आमतौर पर नहीं। Microsoft का दिशानिर्देश है कि केवल तभी Mark the certificate’s private key as exportable चुनें जब यह आवश्यक हो, और यह एक ऐसा मामला बताता है जहां यह जरूरी है: एक Edge Server pool, जहां हर सदस्य को media relay authentication सेवा के लिए वही सर्टिफिकेट और वही private key प्रस्तुत करनी होती है। यदि आप सर्टिफिकेट को किसी reverse proxy या hardware load balancer में ले जाने की योजना बना रहे हैं तो भी आपको इसकी जरूरत है। बाकी सभी मामलों में, key को non-exportable छोड़ दें और प्रति सर्वर अलग रिक्वेस्ट जनरेट करें।
2048-बिट RSA उपयोग करें। Skype for Business Server 1024, 2048 और 4096 की key लंबाइयों को सपोर्ट करता है, और Microsoft 2048 या उससे अधिक की सिफारिश करता है, लेकिन 1024-बिट key सालों से पब्लिक CAs द्वारा जारी नहीं किए जा सके हैं। एक 4096-बिट key स्वीकार की जाती है और उस सर्टिफिकेट के लिए कोई व्यावहारिक सुरक्षा नहीं जोड़ती जो अब अधिकतम 200 दिनों तक चलता है, जबकि हर TLS handshake पर अतिरिक्त CPU खर्च करती है।
नहीं। जो एक्सटेंशन आप -Output में पास करते हैं या wizard के File Name बॉक्स में टाइप करते हैं वह केवल एक लेबल है, और Microsoft का अपना संदर्भ इस पर असंगत है: एक उदाहरण में एक .cer फ़ाइल लिखी गई है और पैरामीटर का विवरण एक .pfx पथ दिखाता है। जो मायने रखता है वह है सामग्री, BEGIN और END मार्कर लाइनों के बीच एक base64 PKCS #10 रिक्वेस्ट। बाद में आसानी से पहचानने के लिए .csr या .req उपयोग करें।
आप कर सकते हैं, लेकिन आप सर्वर पर ऐसा करने का मुख्य लाभ खो देते हैं। कहीं और बनाया गया CSR आपकी topology नहीं पढ़ेगा, इसलिए आपको हर SAN एंट्री हाथ से टाइप करनी होगी और कोई भी गलती reissue का मतलब होगी। आप private key को सर्वर के सर्टिफिकेट स्टोर के बाहर पाएंगे, जिसका मतलब है जारी सर्टिफिकेट को .pfx फ़ाइल में बदलना और मैनुअल तरीके से इंपोर्ट करना। Front End या Edge Server पर रिक्वेस्ट जनरेट करने से key वहीं रहती है जहां Skype for Business इसकी अपेक्षा करता है।
Skype for Business Server 2015 और 2019 का extended support 14 अक्टूबर, 2025 को समाप्त हो गया। पेड Extended Security Updates ने अक्टूबर 2025 से अप्रैल 2026 को कवर किया, और अलग से खरीदने वाले संगठनों के लिए एक दूसरी अवधि मई 2026 से अक्टूबर 2026 के अंत तक कवर करती है। Microsoft ने जुलाई 2026 में फिर पुष्टि की कि इसके बाद कोई और विस्तार नहीं मिलेगा। Skype for Business Server Subscription Edition, 1 जुलाई, 2025 से उपलब्ध, वर्तमान on-premises रिलीज है और Modern Lifecycle Policy का पालन करता है। इस पेज पर बताए गए CSR चरण तीनों पर समान हैं।
आज ऑर्डर करते समय एसएसएल प्रमाणपत्रों पर 10% की बचत करें!
तेजी से जारी करना, मजबूत एन्क्रिप्शन, 99.99% ब्राउज़र ट्रस्ट, समर्पित समर्थन और 25 दिन की मनी-बैक गारंटी। कूपन कोड: SAVE10


