0226 | MS Exchange : CryptographicException: Invalid provider type specified

There’s issue when installing/renewing a certificate to MS Exchange.

System.Security.Cryptography.CryptographicException: Invalid provider type specified

This is the explaination (reference: MS Technet > exchange server 2013 > Unable to access ECP/OWA)

The basic problem is that the Exchange code cannot properly handle X.509 certificates signed with the new and mighty Microsoft Software Key Storage Provider (which is kind of funny)

To fix this, do the following step:

  1. Export the certificate as ‘pfx’ file then remove it from the certificate store.
  2. Open ‘Exchange Management Shell’
  3. Type command certutil -csp "Microsoft RSA SChannel Cryptographic Provider" -importpfx c:\path\to\certificate.pfx note to change ‘c:\path\to\certificate.pfx’ to the path of your certificate exported from step 1.
  4. Type certutil -store my, (see sample output below) Check if the ‘Provider = ‘ line is ‘Microsoft RSA SChannel Cryptographic Provider’. Copy the hash after ‘Cert Hash(sha1):’
  5. Enable the certificate for Exchange. Type Enable-ExchangeCertificate -thumbprint "00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff 01 23 45 67" -Services "iis,pop,imap,smtp"
  6. Restart IIS.
Serial Number: ************
Issuer: CN=WMSvc-***
 NotBefore: 12/24/2014 7:18 PM
 NotAfter: 12/21/2024 7:18 PM
Subject: CN=WMSvc-***
Signature matches Public Key
Root Certificate: Subject matches Issuer
Cert Hash(sha1): 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff 01 23 45 67
  Key Container = WMSvc Certificate Key Container
  Unique container name: *******************************************
  Provider = Microsoft RSA SChannel Cryptographic Provider
Encryption test passed

Tags:

0225 | เน็ตไทยกับ cloudflare

*** ถ้างงตัวย่อแนะนำให้อ่านด้านท้ายก่อนครับ

การเชื่อมต่ออินเทอร์เน็ตในไทยถือว่าเป็นประเทศที่มีการเชื่อมต่อภายในประเทศดีเป็นอันดับต้นๆ ของโลกเลยครับ เนื่องด้วยโครงสร้างของ NIX ที่ค่อนข้างแข็งแรง ถึงแม้ว่าแต่ละ ISP ก็เปิด NIX ของตัวเองกันหมด แต่การเชื่อมต่อเข้าหากันโดยรวมก็ครบถ้วนสมบูรณ์ดี

พอมามองเส้นทางแถวๆ การเชื่อมต่อออกต่างประเทศบ้าง กลายเป็นว่า แต่ละ ISP ก็ต่อออกกันเองกันเกือบหมด ไม่มีการเชื่อมต่อหากันในฝั่ง IIG ทำให้เกิดผังประมาณด้านล่างนี้ครับ

ซึ่ง Cloudflare ในฐานะผู้ให้บริการ content acceleration (เร่งความเร็วในการรับชมเนื้อหาของลูกค้าของ cloudflare) ก็พยายามวางเครื่องให้อยู่ในแทบทุก ISP แต่เนื่องจากเป็นผู้ให้บริการ “จากต่างประเทศ” ก็เลยทำให้ Cloudflare จำเป็นต้องเชื่อมต่ออยู่ตรงขาเส้นทางต่างประเทศ (IIG) ตรงเมฆส้มตามรูปด้านล่างนี้ครับ

*** ทั้งนี้ทั้งนั้น ตัวเครื่อง Server ของ Cloudflare อยู่ในประเทศไทยนะครับ ***

จะสังเกตว่า จาก ISP (ในวงกลม) มายัง IIG เป็นการเชื่อมต่อ “ออก” ทางเดียว (ไม่มีกลับเข้ามา)

และโดยสภาพที่แสนประหลาดของการใช้งานเน็ตในไทย คือกลุ่มผู้ให้บริการเนื้อหา (Content Provider) ดันไม่ได้ไปวาง Server อยู่กับ ISP ที่เป็นผู้ให้บริการอินเทอร์เน็ตตามบ้าน (ดูรายการด้านล่าง) เลยกลายเป็นว่า ร้อยละ 90 ของการเข้าใช้งานเนื้อหาผ่าน Cloudflare ที่ผู้ชม และ server อยู่ในไทย ต้องไปวิ่งอ้อมโลกมา… (ใกล้ไกลแล้วแต่ ISP ไหน) การเข้าใช้งานเว็บไทย ที่ Server อยู่ไทย และใช้ Cloudflare เลยกลายเป็นช้าลงหนักกว่าเดิมเยอะเลยครับ


  • ISP = Internet Service Provide => ผู้ให้บริการอินเทอร์เน็ต (ที่เราใช้กันอยู่ทุกวันนี้ เช่น 3BB, AIS, True, …)
  • NIX = National(Domestic) Internet Exchange => จุดแลกเปลี่ยนข้อมูลภายในประเทศ
  • IIG = International Internet Gateway => จุดเชื่อมโยงข้อมูลกับอินเทอร์เน็ตทั่วโลก

ผู้ให้บริการอินเทอร์เน็ตแก่ผู้ใช้งาน (Last Mile) รายหลัก

  • 3BB
  • AIS
  • CAT
  • DTAC
  • TOT
  • True

ผู้ให้บริการอินเทอร์เน็ตฝั่งศูนย์ข้อมูล (Data Center) รายหลัก

  • CAT
  • CS Loxinfo
  • Internet Thailand
  • Jastel
  • Proen
  • TCCT

Tags: