رفع خطای TLS در تلفن یالینک؛ حل مشکل گواهی نامعتبر یا منقضی‌شده

خطاهایی مانند Certificate Not Trusted، Certificate Expired، Certificate Is Not Yet Valid یا خطای Host Verification معمولاً از یکی از این موارد می‌آیند: زنجیره CA ناقص است، Root یا Intermediate CA داخل Trust Store تلفن وجود ندارد، ساعت Yealink اشتباه است، گواهی منقضی شده، نام SIP Server با Subject Alternative Name گواهی تطابق ندارد یا Server در سناریوی چنددامنه‌ای Certificate اشتباه ارائه می‌دهد.

در این آموزش مسیر TLS را از ابتدا بررسی می‌کنیم: اتصال TCP، Certificate Chain، تاریخ اعتبار، NTP، نام میزبان، CN/SAN، Trust Store و SNI. در پایان نیز توضیح می‌دهیم چرا خاموش‌کردن Certificate Verification فقط باید یک تست موقت برای تشخیص باشد و نباید به راه‌حل دائمی تبدیل شود.

TLS در تلفن Yealink برای چه کاری استفاده می‌شود؟

SIP معمولی می‌تواند روی UDP یا TCP منتقل شود. در حالت TLS، Signaling بین تلفن و SIP Server داخل یک ارتباط رمزگذاری‌شده TLS قرار می‌گیرد.

جریان ساده به این شکل است:

Yealink
↓
TCP Connection
↓
TLS Handshake
↓
Certificate Validation
↓
SIP REGISTER
↓
401 / Authentication
↓
200 OK

نکته مهم این است که اگر TLS Handshake یا Certificate Validation شکست بخورد، ممکن است تلفن اصلاً به مرحله ارسال REGISTER نرسد.

پس وقتی در Capture هیچ REGISTERی نمی‌بینید، الزاماً مشکل Account یا Password نیست.

خطاهای رایج TLS در Yealink چه معنی دارند؟

مرحله اول: مطمئن شوید واقعاً پورت TLS در دسترس است

قبل از بررسی Certificate مطمئن شوید Server روی Port موردنظر TLS را ارائه می‌دهد.

پورت رایج SIP TLS برابر 5061 است، اما این مقدار اجباری نیست و سرویس‌دهنده یا PBX می‌تواند Port دیگری استفاده کند.

تست از ویندوز

Test-NetConnection sip.example.com -Port 5061

اگر:

TcpTestSucceeded : True

می‌بینید، TCP تا آن Port برقرار است.

اما این تست ثابت نمی‌کند Certificate سالم است؛ فقط اتصال TCP را آزمایش می‌کند.

تست از لینوکس

nc -vz sip.example.com 5061

اگر TCP باز است ولی Yealink همچنان Register نمی‌شود، مرحله بعد TLS Handshake است.

مرحله دوم: Certificate سرور را با OpenSSL ببینید

برای مشاهده گواهی‌ای که Server واقعاً ارائه می‌دهد:

openssl s_client -connect sip.example.com:5061 -servername sip.example.com -showcerts

به‌جای:

sip.example.com

نام واقعی SIP Server خود را قرار دهید.

این دستور اطلاعات مهمی نشان می‌دهد:

Certificate اصلی Server.

Intermediate Certificateها.

Issuer.

Subject.

Verification Result.

TLS Version.

Cipher انتخاب‌شده.

خروجی Verify Return Code را بررسی کنید

در انتهای خروجی OpenSSL معمولاً بخشی شبیه این دیده می‌شود:

Verify return code: 0 (ok)

اگر مقدار صفر باشد، سیستم اجراکننده OpenSSL توانسته Chain ارائه‌شده را با Trust Store خودش اعتبارسنجی کند.

اما یک نکته مهم وجود دارد: این نتیجه تضمین نمی‌کند Yealink نیز همان Certificate را Trusted بداند، چون Trust Store کامپیوتر و تلفن ممکن است متفاوت باشند.

Certificate Not Trusted در Yealink دقیقاً چه می‌گوید؟

Yealink هنگام اتصال به Server، Certificate دریافت‌شده را با فهرست Trusted Certificates خودش مقایسه می‌کند.

اگر نتواند یک مسیر اعتماد معتبر از Certificate Server تا یک CA مورد اعتماد ایجاد کند، ممکن است در Syslog پیام مشابه زیر ثبت شود:

Failed to verify the remote certificate
verification failure: certificate not trusted

در این وضعیت اولین کار نباید غیرفعال‌کردن Verification باشد.

ابتدا Certificate Chain سمت Server و Trust Store تلفن را بررسی کنید.

Certificate Chain چیست؟

Certificate Server معمولاً مستقیماً توسط Root CA امضا نشده است. ساختار رایج چنین است:

Root CA
↓
Intermediate CA
↓
Server Certificate

تلفن باید بتواند از Certificate سرور به یک Trust Anchor معتبر برسد.

اگر Server فقط Certificate خودش را ارسال کند و Intermediate لازم را ارسال نکند، بعضی Browserها ممکن است با استفاده از اطلاعات ذخیره‌شده قبلی مشکل را پنهان کنند، اما یک IP Phone می‌تواند Chain را ناقص تشخیص دهد.

با OpenSSL Chain را بررسی کنید

openssl s_client -connect sip.example.com:5061 \
-servername sip.example.com \
-showcerts

در خروجی باید Certificateهای ارسال‌شده توسط Server را ببینید.

اگر فقط Leaf Certificate وجود دارد ولی Issuer آن یک Intermediate CA است، تنظیم Certificate Chain روی Server را بررسی کنید.

Leaf، Intermediate و Root را با هم اشتباه نگیرید

Leaf Certificate همان Certificate متعلق به SIP Server است.

Intermediate CA واسطه‌ای است که Certificate Server را امضا کرده است.

Root CA بالاترین Trust Anchor زنجیره است.

برای Server معمولاً باید Certificate و Intermediateهای لازم به‌صورت Chain صحیح ارائه شوند.

در سمت Yealink نیز CA مورد اعتماد باید در Trusted Certificates وجود داشته باشد.

Trust Store در Yealink کجاست؟

در مدل‌های مختلف نام دقیق منو ممکن است کمی متفاوت باشد، اما در مستندات جدید Yealink مسیر زیر برای مدیریت Certificate ذکر شده است:

Security → Trusted Certificates / Server Certificates

Yealink دو دسته کلی Certificate دارد:

Default Certificates: CAهایی که همراه Firmware تلفن ارائه شده‌اند.

Custom Certificates: CAهایی که Administrator خودش وارد می‌کند.

در مدل‌های فعلی می‌توان انتخاب کرد تلفن از Default، Custom یا هر دو استفاده کند.

فرمت‌های Certificate قابل استفاده در Yealink

در مستندات فعلی بسیاری از مدل‌های Yealink برای Trusted Certificate فرمت‌های زیر ذکر شده‌اند:

.pem
.crt
.cer
.der

پشتیبانی دقیق و محدودیت تعداد یا اندازه فایل می‌تواند بر اساس مدل و Firmware فرق کند؛ بنابراین مستند مدل واقعی تلفن را بررسی کنید.

اگر CA خصوصی دارید چه کنید؟

اگر PBX از Certificate صادرشده توسط CA داخلی شرکت استفاده می‌کند، طبیعی است که Yealink آن CA را به‌صورت پیش‌فرض نشناسد.

مثلاً ساختار شما:

Iranica-Root-CA
↓
Iranica-VoIP-Intermediate
↓
sip.example.com

است.

در این حالت CA موردنیاز را به Trusted Certificates تلفن اضافه کنید و مطمئن شوید Server نیز Intermediateهای لازم را ارائه می‌دهد.

مرحله سوم: تاریخ اعتبار Certificate را بررسی کنید

هر X.509 Certificate یک بازه اعتبار دارد:

Not Before
Not After

قبل از Not Before هنوز معتبر نشده است و بعد از Not After منقضی محسوب می‌شود.

مشاهده تاریخ‌ها با OpenSSL

openssl s_client -connect sip.example.com:5061 \
-servername sip.example.com 2>/dev/null \
| openssl x509 -noout -dates

خروجی نمونه:

notBefore=Oct 10 00:00:00 2026 GMT
notAfter=Jan 08 23:59:59 2027 GMT

Certificate Is Not Yet Valid معمولاً چرا دیده می‌شود؟

Yealink در راهنمای Registration خودش این خطا را مستقیماً ذکر می‌کند:

The certificate is not yet valid

دو علت اصلی دارد.

اول اینکه Certificate واقعاً هنوز وارد بازه اعتبار نشده است.

دوم و بسیار رایج‌تر اینکه ساعت یا تاریخ تلفن اشتباه است.

مثلاً Certificate از:

2026-10-10

معتبر است اما تلفن فکر می‌کند تاریخ:

2024-01-01

است.

در این وضعیت Certificate برای تلفن متعلق به «آینده» است.

مرحله چهارم: NTP و ساعت تلفن را بررسی کنید

در صفحه تلفن ابتدا تاریخ و ساعت فعلی را ببینید.

اگر زمان اشتباه است، Certificate را تغییر ندهید.

موارد زیر را بررسی کنید:

NTP Server.

Time Zone.

DNS مربوط به NTP Server.

دسترسی UDP موردنیاز NTP.

امکان Sync شدن تلفن با Server.

بعد از اصلاح NTP، زمان تلفن را دوباره بررسی و Registration را تکرار کنید.

یک اختلاف کوچک Time Zone معمولاً Not Yet Valid ایجاد نمی‌کند

Certificateها معمولاً بر اساس UTC اعتبارسنجی می‌شوند.

اما اگر ساعت سیستم چند ساعت یا چند روز اشتباه باشد، مشکل ایجاد می‌شود.

پس به‌جای نگاه‌کردن فقط به Time Zone، تاریخ و زمان واقعی دستگاه را هم بررسی کنید.

Certificate Expired چگونه تشخیص داده می‌شود؟

اگر زمان فعلی بعد از مقدار:

Not After

باشد، Certificate منقضی شده است.

مثلاً:

notAfter=Oct 01 23:59:59 2026 GMT

و تاریخ فعلی از آن گذشته باشد، راه‌حل درست تمدید Certificate سمت Server است.

در این حالت Import کردن مجدد همان Certificate قدیمی روی Yealink مشکل را حل نمی‌کند.

بعد از تمدید Certificate چه چیز دیگری ممکن است خراب شود؟

بعد از Renewal ممکن است Leaf Certificate جدید درست باشد اما Server هنوز Intermediate قدیمی یا Chain ناقص ارائه کند.

بنابراین بعد از تمدید دوباره این دستور را اجرا کنید:

openssl s_client -connect sip.example.com:5061 \
-servername sip.example.com \
-showcerts

و Chain کامل را بررسی کنید.

مرحله پنجم: Hostname Verification را بررسی کنید

ممکن است Certificate کاملاً معتبر و توسط CA معتبر صادر شده باشد، اما نام آن با SIP Server شما تطابق نداشته باشد.

مثلاً تلفن به این Server متصل می‌شود:

sip.example.com

اما Certificate فقط برای:

pbx.example.net

صادر شده است.

در صورت فعال‌بودن Name Validation، این Certificate نباید برای sip.example.com معتبر شناخته شود.

CN و SAN چیست؟

گواهی‌های X.509 می‌توانند نام‌های Server را در Subject و مخصوصاً Subject Alternative Name یا SAN داشته باشند.

مثلاً:

DNS:sip.example.com
DNS:pbx.example.com

اگر تلفن به:

sip.example.com

متصل می‌شود، باید هویتی متناسب با همان Domain در Certificate وجود داشته باشد.

Subject Alternative Name را با OpenSSL ببینید

openssl s_client -connect sip.example.com:5061 \
-servername sip.example.com 2>/dev/null \
| openssl x509 -noout -subject -issuer -ext subjectAltName

خروجی ممکن است چیزی شبیه این باشد:

subject=CN=sip.example.com
issuer=CN=Example Intermediate CA

X509v3 Subject Alternative Name:
    DNS:sip.example.com, DNS:pbx.example.com

خطای connect SSL Verify host در Yealink

Yealink در مستندات Registration پیام زیر را برای شکست بررسی نام Host ذکر می‌کند:

connect SSL Verify host

اگر این پیام در Syslog دیده می‌شود، آدرس SIP Server را با CN/SAN Certificate مقایسه کنید.

راه‌حل اصولی این است که Certificate مناسب همان Hostname روی Server نصب شود یا تلفن با نام صحیح Server متصل شود.

اتصال با IP به‌جای Domain می‌تواند دردسرساز شود

فرض کنید Certificate برای:

sip.example.com

صادر شده است.

ولی داخل Yealink این مقدار را وارد کرده‌اید:

203.0.113.20

اگر Certificate هیچ IP SAN مطابقی نداشته باشد، Name Validation ممکن است شکست بخورد.

برای TLS معمولاً استفاده از نام DNS صحیح Server منطقی‌تر از واردکردن مستقیم IP است، مگر Certificate و معماری سرویس شما مشخصاً برای IP طراحی شده باشد.

مرحله ششم: SNI را در سرورهای چنددامنه‌ای بررسی کنید

Server Name Indication یا SNI افزونه‌ای در TLS است که Client می‌تواند هنگام ClientHello نام Server موردنظر را اعلام کند.

این قابلیت زمانی اهمیت زیادی دارد که یک IP چند سرویس TLS یا چند Domain را میزبانی می‌کند.

مثلاً یک IP:

203.0.113.20

این دو سرویس را دارد:

sip-a.example.com
sip-b.example.com

Server باید بداند Client Certificate مربوط به کدام Domain را می‌خواهد.

SNI را با OpenSSL آزمایش کنید

اول اتصال با Server Name:

openssl s_client \
-connect 203.0.113.20:5061 \
-servername sip.example.com \
-showcerts

بعد برای تست، بدون Server Name:

openssl s_client \
-connect 203.0.113.20:5061 \
-showcerts

اگر Certificate ارائه‌شده در این دو حالت متفاوت است، Server از Virtual Hosting مبتنی بر SNI استفاده می‌کند.

اگر Yealink Certificate اشتباه را از Server دریافت کند چه؟

در این حالت ممکن است Server به‌جای Certificate:

sip.example.com

Certificate مربوط به یک Virtual Host دیگر را ارائه دهد.

نتیجه می‌تواند Hostname Verification Failure باشد.

نکته مهم این است که در مستندات Yealink که برای مدل‌های فعلی بررسی شده‌اند، گزینه عمومی و مستقلی با عنوان «SIP SNI» در تنظیمات رایج TLS نمایش داده نشده است.

بنابراین اگر معماری شما به SNI وابسته است، رفتار دقیق مدل و Firmware تلفن و تنظیم Virtual Host سمت SBC یا SIP Server را بررسی کنید. صرفاً فرض نکنید همه مدل‌ها و Firmwareها رفتار یکسانی دارند.

RFC مربوط به SIP و Certificate درباره Virtual Hosting چه می‌گوید؟

RFC 5922 برای SIP روی TLS توضیح می‌دهد که در سناریوهای Virtual Hosting، اگر TLS Client از Server Name Extension پشتیبانی کند، استفاده از آن برای درخواست Certificate مربوط به Domain موردنظر مناسب است.

این موضوع نشان می‌دهد SNI در معماری SIP TLS چنددامنه‌ای واقعاً مهم است، اما پشتیبانی Endpoint باید جداگانه بررسی شود.

مرحله هفتم: نسخه TLS را بررسی کنید

پشتیبانی نسخه TLS بین مدل‌ها و Firmwareهای Yealink یکسان نیست.

مستندات مدل‌های جدیدتر می‌توانند گزینه‌هایی مانند:

TLS 1.0
TLS 1.1
TLS 1.2
TLS 1.3

را نشان دهند، در حالی که بعضی مدل‌ها یا Firmwareها محدودتر هستند.

پس قبل از اجبار Server به TLS 1.3 یا حذف کامل TLS 1.2، قابلیت مدل واقعی Yealink را بررسی کنید.

نسخه TLS Server را با OpenSSL تست کنید

برای TLS 1.2:

openssl s_client \
-connect sip.example.com:5061 \
-servername sip.example.com \
-tls1_2

اگر Server و Client از TLS 1.3 پشتیبانی می‌کنند:

openssl s_client \
-connect sip.example.com:5061 \
-servername sip.example.com \
-tls1_3

اگر فقط یکی از این نسخه‌ها کار می‌کند، تنظیم Version در Yealink و Server را مقایسه کنید.

Cipher Suite هم می‌تواند TLS Handshake را متوقف کند

اگر Client و Server هیچ Cipher مشترکی نداشته باشند، TLS Handshake کامل نمی‌شود.

این مشکل بیشتر زمانی دیده می‌شود که Security Policy سرور بسیار سخت‌گیرانه شده یا Firmware تلفن قدیمی است.

در چنین شرایطی به‌جای فعال‌کردن Cipherهای قدیمی و ناامن، ابتدا Firmware رسمی جدید تلفن را بررسی کنید.

مرحله هشتم: Syslog Yealink را بگیرید

چون SIP داخل TLS رمزگذاری می‌شود، PCAP به‌تنهایی مثل UDP SIP قابل خواندن نیست.

برای TLS، Syslog تلفن اهمیت بسیار بیشتری دارد.

Yealink در راهنمای عیب‌یابی خودش پیشنهاد می‌کند در صورت ادامه مشکل Diagnostic Files شامل موارد زیر تهیه شوند:

config.bin
PCAP
Level 6 Syslog

ابتدا Capture و Log را Start کنید، Registration را بازتولید کنید و سپس فایل‌ها را Export کنید.

در Syslog دنبال چه عبارت‌هایی بگردیم؟

جست‌وجوی این عبارت‌ها مفید است:

certificate
SSL
TLS
verify
trusted
valid
host

سه پیام مهمی که خود Yealink در مستندات Registration آورده است عبارت‌اند از:

certificate not trusted

The certificate is not yet valid

connect SSL Verify host

در TLS ممکن است هیچ REGISTER در PCAP نبینید

اگر Certificate Verification قبل از شروع SIP شکست بخورد، تلفن ممکن است اصلاً REGISTER را ارسال نکند.

در این حالت Flow می‌تواند این‌طور باشد:

TCP SYN
TCP SYN/ACK
TLS ClientHello
TLS ServerHello
Certificate
TLS Alert
Connection Close

و هیچ SIP REGISTERی وجود ندارد.

این رفتار به شما می‌گوید مشکل قبل از مرحله SIP Authentication رخ داده است.

Trust Certificates در Yealink چگونه تنظیم می‌شود؟

در مستندات مدل‌های جدید پارامتری مانند:

static.security.trust_certificates

برای فعال یا غیرفعال‌کردن اعتبارسنجی Certificate وجود دارد.

همچنین:

static.security.ca_cert

برای تعیین نوع CAهای مورد استفاده به‌کار می‌رود.

مقادیر مستندشده می‌توانند شامل:

Default Certificates
Custom Certificates
All Certificates

باشند.

نام دقیق پارامتر در بعضی Firmwareها می‌تواند متفاوت باشد؛ بنابراین Config Reference همان مدل را بررسی کنید.

Common Name Validation در Yealink

Yealink پارامترهایی برای اعتبارسنجی CN یا SubjectAltName نیز دارد.

در مستندات فعلی می‌توان پارامتری مانند:

static.security.cn_validation

یا در بعضی مدل‌ها تنظیم مرتبط با SIP مانند:

security.sip.cn_validation

را مشاهده کرد.

فعال‌بودن این قابلیت باعث می‌شود نام Certificate به‌صورت سخت‌گیرانه‌تر با Server بررسی شود.

غیرفعال‌کردن Certificate Verification فقط برای تست

Yealink در راهنمای عیب‌یابی Registration اشاره می‌کند که برای تشخیص می‌توان Trust Certificate Validation را غیرفعال کرد.

در بعضی Firmwareها پارامتری شبیه:

security.trust_certificates=0

و در مستندات جدیدتر:

static.security.trust_certificates=0

دیده می‌شود.

اگر با غیرفعال‌کردن Verification تلفن فوراً Register شد، شما ثابت کرده‌اید مشکل به احتمال زیاد در Certificate Validation است.

اما این فقط یک تست تشخیصی است.

چرا Verification را نباید خاموش نگه داریم؟

هدف TLS فقط رمزگذاری نیست؛ یکی از اهداف اصلی آن Authentication Server است.

اگر تلفن هر Certificateای را قبول کند، دیگر نمی‌تواند مطمئن شود واقعاً به SIP Server موردنظر متصل شده است.

در نتیجه امنیت در برابر Server جعلی یا حملات Man-in-the-Middle کاهش پیدا می‌کند.

بعد از تست، Verification را دوباره فعال و علت اصلی را اصلاح کنید.

خاموش‌کردن CN Validation هم راه‌حل نهایی نیست

Yealink برای خطای Host Verification امکان غیرفعال‌کردن CN Validation دارد، اما این کار نیز فقط می‌تواند برای تست مفید باشد.

اگر با خاموش‌کردن CN Validation رجیستر برقرار شد، نتیجه مهم این است:

Certificate از نظر نام با SIP Server شما تطابق ندارد.

راه‌حل اصولی نصب Certificate درست یا اصلاح Hostname است.

چطور بدون کاهش امنیت مشکل را درست کنیم؟

اگر Certificate Not Trusted دارید:

Chain سرور را کامل کنید و CA مناسب را به Trust Store Yealink اضافه کنید.

اگر Certificate Not Yet Valid دارید:

NTP و ساعت تلفن را اصلاح کنید.

اگر Expired است:

Certificate سرور را تمدید کنید.

اگر Host Verification شکست می‌خورد:

Certificate با SAN صحیح نصب کنید یا SIP Server Address را به نام صحیح تغییر دهید.

اگر فقط در Virtual Hosting مشکل دارید:

SNI و Certificate Selection سمت SIP Proxy یا SBC را بررسی کنید.

سناریوی اول: فقط Yealink Certificate Not Trusted می‌دهد

اگر Browser یا OpenSSL Certificate را معتبر می‌دانند ولی Yealink آن را Trusted نمی‌داند، Trust Store دو دستگاه را مقایسه کنید.

ممکن است Root CA جدید در سیستم‌عامل کامپیوتر وجود داشته باشد اما Firmware Yealink قدیمی آن را نداشته باشد.

راه‌حل می‌تواند Import کردن CA موردنیاز به Trusted Certificates باشد.

سناریوی دوم: همه Yealinkها ناگهان از رجیستر خارج شده‌اند

اگر تعداد زیادی تلفن در یک زمان مشخص TLS Registration را از دست داده‌اند، قبل از Reset کردن تلفن‌ها Server Certificate را بررسی کنید.

موارد محتمل:

Certificate منقضی شده است.

Certificate جدید با Chain ناقص نصب شده است.

Intermediate CA تغییر کرده است.

Certificate جدید SAN درست ندارد.

SBC Certificate اشتباه ارائه می‌دهد.

سناریوی سوم: فقط بعد از Reboot مشکل ایجاد می‌شود

گاهی Connection قدیمی TLS قبل از تغییر Certificate برقرار بوده است و مشکل بعد از Reboot یا Reconnect ظاهر می‌شود.

در این حالت تلفن مجبور می‌شود TLS Handshake جدید انجام دهد و Certificate جدید را اعتبارسنجی کند.

پس اگر مشکل دقیقاً بعد از Restart شروع شده، زمان تغییر Certificate سمت Server را بررسی کنید.

سناریوی چهارم: با Domain خراب است ولی با IP وصل می‌شود

این نتیجه را با احتیاط تفسیر کنید.

ممکن است Domain به Server دیگری Resolve شود.

ممکن است SNI باعث انتخاب Certificate متفاوت شود.

یا ممکن است CN Validation در یکی از سناریوها متفاوت عمل کند.

این تست به‌تنهایی ثابت نمی‌کند DNS مقصر است.

سناریوی پنجم: با IP خراب است ولی با Domain کار می‌کند

این وضعیت برای TLS کاملاً منطقی است.

Certificate ممکن است برای:

sip.example.com

صادر شده باشد اما IP داخل SAN آن وجود نداشته باشد.

اگر Name Validation فعال باشد، اتصال با Domain موفق و اتصال مستقیم با IP نامعتبر خواهد بود.

سناریوی ششم: OpenSSL با -servername کار می‌کند اما بدون آن Certificate دیگری می‌آید

این یکی از نشانه‌های مهم Virtual Hosting مبتنی بر SNI است.

مثلاً با:

-servername sip.example.com

Certificate صحیح:

sip.example.com

دریافت می‌شود.

اما بدون SNI:

default.example.net

برمی‌گردد.

در این حالت رفتار واقعی Yealink، Firmware و تنظیم SBC باید بررسی شود.

سناریوی هفتم: TLS Port باز است اما هیچ REGISTER نداریم

Port باز به معنی TLS سالم نیست.

اگر:

Test-NetConnection

موفق است ولی Yealink Register نمی‌شود، Syslog و TLS Handshake را بررسی کنید.

Certificate Validation می‌تواند قبل از SIP REGISTER اتصال را متوقف کند.

چک‌لیست نهایی رفع خطای TLS Yealink

پرسش‌های متداول درباره TLS در Yealink

Certificate Not Trusted در Yealink یعنی چه؟

یعنی تلفن نتوانسته Certificate ارائه‌شده توسط SIP Server را از طریق یک Chain معتبر به CA مورد اعتماد داخل Trust Store خودش متصل کند. CA Chain و Trusted Certificates را بررسی کنید.

خطای Certificate Is Not Yet Valid از چیست؟

یا Certificate واقعاً هنوز وارد بازه اعتبار نشده یا ساعت و تاریخ Yealink اشتباه است. ابتدا NTP و زمان تلفن را بررسی کنید.

اگر Certificate منقضی شده باشد چه کنیم؟

Certificate باید روی SIP Server یا SBC تمدید شود. غیرفعال‌کردن Verification راه‌حل مناسبی برای Certificate منقضی‌شده نیست.

connect SSL Verify host چه معنی دارد؟

این خطا به شکست اعتبارسنجی نام Server مربوط است. آدرس SIP Server را با CN یا Subject Alternative Name گواهی مقایسه کنید.

آیا می‌توان CA اختصاصی را به Yealink اضافه کرد؟

بله. مدل‌های Yealink امکان Import کردن Custom Trusted Certificates را دارند. فرمت‌ها و محدودیت‌ها را باید با مستند همان مدل و Firmware تطبیق دهید.

آیا می‌توان Certificate Verification را خاموش کرد؟

Yealink چنین گزینه‌ای دارد، اما برای عیب‌یابی باید فقط موقتاً استفاده شود. اگر با خاموش‌شدن Verification رجیستر درست شد، Certificate یا Trust Store را اصلاح کنید و Verification را دوباره فعال کنید.

SNI چه ارتباطی با SIP TLS دارد؟

در Serverهایی که چند Domain را روی یک IP میزبانی می‌کنند، SNI به Server کمک می‌کند Certificate مناسب Domain را انتخاب کند. پشتیبانی و رفتار دقیق SNI باید برای مدل و Firmware Yealink و همچنین SBC یا SIP Server بررسی شود.

چرا OpenSSL Certificate را معتبر می‌داند ولی Yealink قبول نمی‌کند؟

Trust Store کامپیوتر و Yealink یکسان نیست. ممکن است سیستم‌عامل شما Root CA جدید را داشته باشد ولی تلفن آن CA را نشناسد یا Chain Server برای دستگاه‌های Embedded کامل نباشد.

جمع‌بندی

برای رفع خطای TLS در Yealink، اولین کار خاموش‌کردن Certificate Verification نیست. ابتدا مشخص کنید مشکل دقیقاً در کدام مرحله قرار دارد: TCP، TLS Handshake، Chain Validation، تاریخ Certificate، Trust Store یا Hostname Verification.

اگر Certificate Not Trusted دارید، Chain و CA را بررسی کنید. اگر Not Yet Valid می‌بینید، قبل از هر چیز NTP و زمان تلفن را کنترل کنید. اگر Certificate منقضی است، آن را روی Server تمدید کنید. اگر Host Verification شکست می‌خورد، CN/SAN باید با نام واقعی SIP Server سازگار باشد.

در محیط‌های چنددامنه‌ای، Certificate ارائه‌شده با و بدون SNI را نیز مقایسه کنید. اگر Server بر اساس SNI Certificate متفاوتی ارائه می‌دهد، رفتار مدل و Firmware Yealink و تنظیم Virtual Host روی SBC اهمیت پیدا می‌کند. در نهایت، غیرفعال‌کردن Trust یا CN Validation فقط باید یک تست موقت برای تأیید محل مشکل باشد؛ راه‌حل نهایی باید زنجیره اعتماد و هویت Server را درست کند.