تنظیم ساعت و NTP در تلفن یالینک؛ رفع خطای TLS و مشکل رجیستر

این مشکل بیشتر زمانی دیده می‌شود که Yealink بعد از روشن‌شدن نتواند از NTP زمان صحیح بگیرد، DHCP یک NTP Server اشتباه ارائه دهد، تلفن به DNS دسترسی نداشته باشد یا تنظیم اولویت NTP باعث شود دستگاه به‌جای Server دستی از آدرس نامعتبر DHCP استفاده کند.

در این آموزش بررسی می‌کنیم Yealink زمان را از کجا می‌گیرد، DHCP Option 42 چه نقشی دارد، DNS و UDP 123 چگونه روی NTP اثر می‌گذارند، Time Zone چه تفاوتی با ساعت واقعی سیستم دارد و چطور با Packet Capture و Syslog مشخص کنیم مشکل TLS واقعاً از زمان دستگاه است یا علت دیگری دارد.

چرا ساعت Yealink روی TLS و رجیستر SIP اثر می‌گذارد؟

Certificateهای TLS فقط بین دو تاریخ مشخص معتبر هستند. در ساختار X.509 این بازه با دو مقدار تعریف می‌شود:

Not Before
Not After

برای مثال یک Certificate ممکن است چنین اعتباری داشته باشد:

Not Before: Oct 10 00:00:00 2026 GMT
Not After : Jan 08 23:59:59 2027 GMT

اگر تاریخ واقعی ۲۰۲۶ باشد اما Yealink تصور کند هنوز سال ۲۰۲۴ است، Certificate برای تلفن هنوز وارد بازه اعتبار نشده است.

نتیجه ممکن است خطایی مانند این باشد:

The certificate is not yet valid

برعکس، اگر ساعت تلفن جلوتر از تاریخ واقعی باشد و از مقدار Not After عبور کند، Certificate می‌تواند از نگاه دستگاه Expired به نظر برسد.

یعنی TLS قبل از SIP Register متوقف می‌شود

در SIP روی TLS، ترتیب ساده ارتباط چنین است:

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

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

بنابراین وقتی Account روی TLS رجیستر نمی‌شود، همیشه User Name و Password را مقصر ندانید.

نشانه‌های اینکه ساعت تلفن مشکل دارد

Yealink ساعت را از کجا می‌گیرد؟

در مدل‌های فعلی Yealink، NTP Server می‌تواند به دو روش اصلی تعیین شود:

به‌صورت دستی در تنظیمات تلفن.

یا از طریق DHCP Server.

در رابط وب بسیاری از مدل‌ها تنظیمات زمان در مسیر زیر قرار دارند:

Settings → Time & Date

بسته به مدل ممکن است نام منو کمی متفاوت باشد.

پارامترهای مهم NTP در Yealink

Yealink در مستندات فعلی پارامترهایی مانند موارد زیر را برای مدیریت زمان تعریف کرده است:

local_time.manual_ntp_srv_prior
local_time.dhcp_time
local_time.ntp_server1
local_time.ntp_server2
local_time.interval
local_time.time_zone
local_time.time_zone_name

این پارامترها مشخص می‌کنند تلفن از کدام NTP Server استفاده کند، چند وقت یک بار زمان را Sync کند و Time Zone چه باشد.

NTP Server اول و دوم

Yealink امکان تعریف Primary و Secondary NTP Server را دارد.

پارامترهای رایج:

local_time.ntp_server1
local_time.ntp_server2

اگر Server اول قابل دسترسی نباشد، تلفن می‌تواند سراغ Server دوم برود.

آدرس NTP Server می‌تواند IP یا Domain باشد.

اگر NTP Server به‌صورت Domain باشد، DNS هم وارد ماجرا می‌شود

فرض کنید این مقدار را تنظیم کرده‌اید:

ntp.example.com

قبل از ارسال درخواست NTP، تلفن باید این نام را به IP تبدیل کند.

اگر DNS تلفن خراب باشد، NTP نیز کار نمی‌کند.

در این حالت ممکن است مشکل ظاهراً «زمان» باشد اما ریشه آن DNS باشد.

DNS Server تلفن را بررسی کنید

در تنظیمات Network تلفن، Primary و Secondary DNS را بررسی کنید.

از یک سیستم داخل همان VLAN یا شبکه نیز می‌توانید Domain را تست کنید:

nslookup ntp.example.com

در Linux:

dig A ntp.example.com +short

اگر هیچ IP معتبری برنمی‌گردد، NTP با Domain نیز نمی‌تواند کار کند.

اگر NTP یا SIP Server شما روی زیرساخت Linux قرار دارد و DNS سمت سرور نیز مشکوک است، راهنمای رفع مشکل DNS و systemd-resolved در Ubuntu می‌تواند برای بررسی سمت سرور مفید باشد.

DHCP Option 42 چیست؟

یکی از مهم‌ترین بخش‌های این مشکل DHCP Option 42 است.

طبق RFC 2132، DHCP Option 42 برای ارائه فهرست IPهای NTP Server به Client استفاده می‌شود.

برای مثال DHCP Server می‌تواند به تلفن بگوید:

Option 42:
10.10.10.10
10.10.10.11

در این شرایط Yealink می‌تواند بدون اینکه Administrator به‌صورت دستی NTP Server وارد کند، این آدرس‌ها را از DHCP بگیرد.

Yealink از DHCP Option 42 پشتیبانی می‌کند

Yealink در مستندات رسمی DHCP خود Option 42 را برای Network Time Protocol Server معرفی کرده است.

این Option باید شامل IP سرورهای NTP باشد.

اگر Option 42 اشتباه تنظیم شده باشد، تعداد زیادی تلفن داخل یک VLAN می‌توانند هم‌زمان ساعت اشتباه داشته باشند.

یک سناریوی رایج در شبکه سازمانی

فرض کنید روی تمام تلفن‌ها به‌صورت دستی این NTP Server را تنظیم کرده‌اید:

10.10.10.20

اما DHCP Server این مقدار را در Option 42 می‌فرستد:

192.168.50.10

و آدرس دوم دیگر وجود ندارد.

اگر Yealink طوری تنظیم شده باشد که NTP دریافتی از DHCP اولویت بیشتری داشته باشد، تلفن ممکن است NTP دستی شما را نادیده بگیرد.

اولویت DHCP NTP و NTP دستی در Yealink

پارامتر:

local_time.manual_ntp_srv_prior

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

در مستندات فعلی Yealink:

0 = DHCP NTP Server اولویت بالاتر دارد
1 = NTP Server دستی اولویت بالاتر دارد

بنابراین اگر NTP دستی صحیح است ولی تلفن همچنان به Server دیگری درخواست می‌فرستد، این تنظیم را بررسی کنید.

DHCP Option 2 چیست؟

Yealink علاوه بر Option 42، DHCP Option 2 را نیز پشتیبانی می‌کند.

Option 2 مقدار Time Offset نسبت به UTC را ارائه می‌دهد.

برای مثال:

UTC + 3:30

باید به Offset متناظر تبدیل شود.

Yealink پارامتر:

local_time.dhcp_time

را برای استفاده از Offset ارائه‌شده توسط DHCP دارد.

این بخش را با Option 42 اشتباه نگیرید:

Option 42 آدرس NTP Server را می‌دهد.

Option 2 Offset زمانی را ارائه می‌کند.

Time Zone و ساعت واقعی یک چیز نیستند

این نکته برای عیب‌یابی TLS بسیار مهم است.

NTP اساساً زمان مطلق را Synchronize می‌کند. Time Zone مشخص می‌کند آن زمان برای کاربر محلی چگونه نمایش داده شود.

اگر زمان مطلق تلفن درست باشد اما فقط Time Zone اشتباه تنظیم شده باشد، صرفاً دیدن ساعت محلی اشتباه الزاماً ثابت نمی‌کند TLS نیز Certificate را با زمان اشتباه بررسی می‌کند.

اما اگر خود Clock دستگاه واقعاً چند ساعت یا چند روز جابه‌جا شده باشد، اعتبار Certificate می‌تواند شکست بخورد.

بنابراین فقط به نوشته روی صفحه نگاه نکنید؛ منبع زمان و Sync شدن NTP را هم بررسی کنید.

Time Zone در Yealink کجا تنظیم می‌شود؟

در همان بخش Time & Date می‌توانید منطقه زمانی را تنظیم کنید.

پارامترهای رایج:

local_time.time_zone
local_time.time_zone_name

اگر تلفن‌ها در چند شعبه یا کشور مختلف هستند، Auto Provisioning باید Time Zone مناسب هر گروه را اعمال کند.

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

روی صفحه Yealink تاریخ و ساعت را یادداشت کنید.

آن را با یک سیستم سالم در همان شبکه یا یک NTP-synchronized Server مقایسه کنید.

اگر اختلاف چند ثانیه‌ای است، معمولاً برای Certificate مسئله جدی نیست.

اگر اختلاف چند ساعت، روز یا سال است، NTP باید بررسی شود.

مرحله عملی دوم: NTP Server فعال را پیدا کنید

در رابط وب تلفن مقادیر Primary و Secondary NTP را ببینید.

اگر DHCP نیز NTP ارائه می‌کند، فقط به این صفحه اکتفا نکنید.

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

برای این کار Packet Capture بهترین روش است.

Packet Capture از Yealink بگیرید

در بسیاری از مدل‌های Yealink وارد:

Settings → Configuration

شوید.

در Export All Diagnostic Files روی Start کلیک کنید.

تلفن را Reboot کنید یا شرایطی ایجاد کنید که دوباره زمان را Sync کند.

بعد از بازتولید مشکل Stop و سپس Export را بزنید.

در مدل‌های فعلی Yealink هنگام گرفتن Diagnostic، Syslog نیز با سطح بالا جمع‌آوری می‌شود.

در Wireshark ترافیک NTP را پیدا کنید

فیلتر:

ntp

را وارد کنید.

اگر تلفن NTP Request ارسال کرده باشد، باید بسته‌هایی بین Yealink و NTP Server ببینید.

NTP معمولاً از UDP Port 123 استفاده می‌کند.

اگر Request وجود دارد ولی Response وجود ندارد، مشکل می‌تواند در:

Firewall.

ACL.

Routing.

NTP Server.

یا UDP 123 باشد.

اگر هیچ NTP Packet دیده نمی‌شود چه؟

در این حالت چند احتمال وجود دارد:

NTP Server تنظیم نشده است.

تلفن هنوز زمان Sync را شروع نکرده است.

DHCP مقدار اشتباه داده است.

Domain مربوط به NTP Resolve نشده است.

یا Priority تنظیمات باعث شده Server دیگری استفاده شود.

اگر NTP Server به‌صورت Domain است، DNS را هم در PCAP ببینید

از فیلتر:

dns

استفاده کنید.

به دنبال Query مربوط به Domain NTP باشید:

ntp.example.com

اگر DNS Query ارسال می‌شود اما Response ندارد، NTP هنوز فرصت شروع نخواهد داشت.

اگر DNS پاسخ NXDOMAIN می‌دهد، نام Server اشتباه است.

DHCP را هم در همان Capture بررسی کنید

اگر تلفن بعد از Reboot IP می‌گیرد، Packetهای DHCP را بررسی کنید.

در نسخه‌های جدید Wireshark می‌توانید از فیلتر:

dhcp

استفاده کنید.

DHCP Offer یا ACK را باز کنید و Options را ببینید.

به‌طور خاص دنبال:

Option 42 - Network Time Protocol Servers
Option 2  - Time Offset
Option 6  - Domain Name Server

باشید.

چرا Option 6 برای NTP هم مهم می‌شود؟

DHCP Option 6 آدرس DNS Server را ارائه می‌دهد.

اگر NTP Server به‌صورت IP از Option 42 آمده باشد، DNS برای همان مقصد لازم نیست.

اما اگر NTP Server را دستی به‌صورت Domain تنظیم کرده‌اید، DNS سالم ضروری است.

پس خرابی Option 6 می‌تواند غیرمستقیم NTP را خراب کند.

یک مثال واقعی از زنجیره خرابی

فرض کنید تلفن این تنظیم را دارد:

Primary NTP:
ntp.company.local

اما DHCP به تلفن DNS اشتباه می‌دهد:

DNS:
192.168.100.50

DNS پاسخ نمی‌دهد.

در نتیجه:

Yealink
↓
DNS Query for ntp.company.local
↓
No Response
↓
NTP Server IP پیدا نمی‌شود
↓
ساعت Sync نمی‌شود
↓
Clock قدیمی باقی می‌ماند
↓
TLS Certificate = Not Yet Valid
↓
SIP Registration Failed

در ظاهر مشکل TLS است، اما علت اصلی DHCP/DNS بوده است.

سناریوی دیگر: DHCP Option 42 اشتباه است

فرض کنید DNS سالم است و NTP دستی نیز صحیح است.

اما DHCP Option 42 این IP را می‌دهد:

10.20.30.40

و آن Server دیگر وجود ندارد.

اگر NTP دریافتی DHCP اولویت داشته باشد، تلفن ممکن است مدام به همین IP درخواست بفرستد و NTP دستی شما استفاده نشود.

در PCAP مقصد NTP Request حقیقت را مشخص می‌کند.

چطور بفهمیم NTP Server پاسخ می‌دهد؟

در Wireshark یک NTP Request و Response را پیدا کنید.

جریان سالم تقریباً چنین است:

Yealink → NTP Server    UDP/123 Request
NTP Server → Yealink    UDP/123 Response

اگر Request خارج می‌شود اما هیچ Response برنمی‌گردد، مسیر برگشت و Firewall را بررسی کنید.

Firewall باید UDP 123 را اجازه دهد

اگر NTP Server خارج از شبکه است، مسیر UDP Port 123 باید مجاز باشد.

در شبکه‌های سازمانی ممکن است فقط NTP داخلی مجاز باشد و درخواست به Public NTP مسدود شود.

در این شرایط بهتر است تلفن‌ها به NTP Server داخلی سازمان هدایت شوند.

برای NTP سازمانی بهتر است یک منبع مشخص داشته باشید

اگر صدها تلفن Yealink دارید، اینکه هر تلفن به یک Public NTP متفاوت وصل شود مدیریت را سخت‌تر می‌کند.

می‌توانید یک یا چند NTP Server داخلی تعریف کنید و آن‌ها را از طریق DHCP Option 42 به VLAN تلفن‌ها بدهید.

در این صورت تغییر NTP نیاز به ویرایش تک‌تک تلفن‌ها ندارد.

Primary و Secondary NTP را واقعاً تست کنید

فقط وجود مقدار Secondary Server کافی نیست.

برای آزمایش Failover، در محیط کنترل‌شده Primary را موقتاً از دسترس خارج کنید و ببینید تلفن سراغ Secondary می‌رود یا خیر.

بعد از تست، تنظیمات یا Firewall را به وضعیت اصلی برگردانید.

Update Interval چه کاری انجام می‌دهد؟

پارامتر:

local_time.interval

تعیین می‌کند تلفن هر چند ثانیه برای به‌روزرسانی زمان اقدام کند.

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

بدون دلیل Interval را بسیار کوتاه نکنید؛ NTP برای Polling منطقی طراحی شده است و Sync بیش از حد لازم فقط ترافیک اضافی تولید می‌کند.

چرا تنظیم دستی ساعت راه‌حل دائمی نیست؟

ممکن است برای تست، ساعت Yealink را دستی صحیح کنید و TLS ناگهان کار کند.

این یک تست بسیار ارزشمند است؛ چون ارتباط مشکل با Clock را نشان می‌دهد.

اما اگر بعد از Reboot ساعت دوباره اشتباه شود، مشکل اصلی هنوز باقی است.

راه‌حل دائمی اصلاح NTP، DHCP یا DNS است.

چطور Certificate را با ساعت تلفن مقایسه کنیم؟

از یک سیستم Linux یا سیستمی که 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

حالا زمان واقعی تلفن را با این بازه مقایسه کنید.

اگر Yealink قبل از Not Before است، خطای Not Yet Valid منطقی است.

اگر بعد از Not After است، Certificate از دید تلفن Expired خواهد بود.

Certificate Validation به زمان مطلق نیاز دارد

در استاندارد X.509، بازه اعتبار Certificate با Not Before و Not After مشخص می‌شود.

به همین دلیل Clock یک جزء امنیتی است، نه فقط یک گزینه ظاهری.

سیستمی که زمان قابل اعتماد ندارد، نمی‌تواند با اطمینان تشخیص دهد یک Certificate اکنون معتبر است یا خیر.

Syslog Yealink را همزمان با NTP بررسی کنید

Yealink پیشنهاد می‌کند برای عیب‌یابی مشکلات قابل بازتولید، Diagnostic Files شامل PCAP، Syslog سطح 6 و Configuration جمع‌آوری شوند.

در Log دنبال عبارت‌هایی مانند این بگردید:

NTP
SNTP
time
DNS
certificate
SSL
TLS
not yet valid

ترتیب زمانی Log بسیار مهم است.

ممکن است ابتدا ببینید NTP Fail شده و چند ثانیه بعد TLS با Certificate Error متوقف شده است.

مثال یک Trace منطقی

Phone Boot
↓
DHCP ACK received
↓
Option 42 = 10.10.10.10
↓
NTP Request → 10.10.10.10
↓
No Response
↓
Old system time remains
↓
TLS connection starts
↓
Certificate received
↓
Certificate is not yet valid
↓
SIP Registration Failed

در چنین حالتی تغییر Certificate یا Password هیچ مشکلی را حل نمی‌کند.

اگر ساعت بعد از Boot اشتباه است ولی چند دقیقه بعد درست می‌شود

این وضعیت می‌تواند نشان دهد Sync با تأخیر انجام می‌شود.

بررسی کنید:

DNS چه مدت طول می‌کشد.

NTP Server اول Timeout می‌شود یا نه.

Secondary Server بعد از چه مدت استفاده می‌شود.

TLS Registration قبل از NTP Sync شروع می‌شود یا بعد از آن.

ممکن است در Boot اولیه Registration Fail شود و بعد از Sync زمان، Retry بعدی موفق شود.

اگر بعد از چند دقیقه خودکار رجیستر می‌شود

این یکی از سرنخ‌های مفید است.

در Syslog بررسی کنید آیا درست قبل از Registration موفق، Time Synchronization انجام شده است یا خیر.

اگر بله، مشکل Certificate و Clock به هم مرتبط هستند.

اگر تلفن زمان درست دارد اما Not Yet Valid می‌دهد

در این حالت فرض نکنید فقط NTP مقصر است.

خود Certificate را بررسی کنید.

ممکن است Certificate تازه صادر شده و Not Before آن واقعاً در آینده باشد.

یا SIP Server پشت Load Balancer قرار داشته باشد و یکی از Nodeها Certificate متفاوتی ارائه دهد.

با OpenSSL همان Server واقعی و در صورت وجود چند IP، هر IP را جداگانه بررسی کنید.

اگر همه تلفن‌ها همزمان ساعتشان خراب شده است

احتمال خرابی تک‌تک تلفن‌ها بسیار پایین است.

موارد مشترک را بررسی کنید:

DHCP Server.

Option 42.

DNS Server.

NTP Server داخلی.

Firewall.

VLAN Voice.

Provisioning Template.

اگر تغییر جدیدی در DHCP یا Firewall انجام شده، زمان آن را با شروع مشکل مقایسه کنید.

اگر فقط یک مدل Yealink مشکل دارد

Firmware همان مدل را بررسی کنید.

همچنین Configuration Template ممکن است برای آن مدل پارامتر NTP متفاوتی داشته باشد.

یک تلفن سالم و خراب را کنار هم قرار دهید و این موارد را مقایسه کنید:

Firmware
NTP Server
DHCP NTP Priority
Time Zone
DNS
Update Interval

Factory Reset اولین راه‌حل نیست

اگر DHCP Server آدرس NTP اشتباه می‌دهد، Factory Reset چیزی را حل نمی‌کند.

تلفن بعد از Reset دوباره همان Option اشتباه را از DHCP خواهد گرفت.

ابتدا منبع تنظیم نادرست را پیدا کنید.

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

برای تشخیص TLS ممکن است در بعضی مدل‌های Yealink بتوان Trust Validation را موقتاً غیرفعال کرد.

اما این روش برای مشکل NTP توصیه نمی‌شود مگر فقط برای اثبات اینکه Failure در مرحله Certificate Validation رخ می‌دهد.

راه‌حل صحیح این است که ساعت تلفن درست شود.

خاموش‌کردن Verification باعث می‌شود تلفن هویت Server را با سخت‌گیری لازم بررسی نکند.

بهترین ترتیب عیب‌یابی

پرسش‌های متداول درباره تنظیم NTP یالینک

ساعت اشتباه Yealink واقعاً می‌تواند باعث Register Failed شود؟

بله، مخصوصاً وقتی SIP Account از TLS استفاده می‌کند. اگر Clock تلفن خارج از بازه Not Before و Not After گواهی باشد، Certificate Validation می‌تواند شکست بخورد و Registration قبل از ارسال یا تکمیل REGISTER متوقف شود.

DHCP Option 42 در Yealink چه کاری انجام می‌دهد؟

Option 42 فهرست IPهای NTP Server را از DHCP Server به تلفن ارائه می‌کند. Yealink از این Option پشتیبانی می‌کند و می‌تواند NTP دریافتی از DHCP را به‌جای تنظیم دستی استفاده کند.

چرا NTP دستی تنظیم کرده‌ام ولی تلفن به Server دیگری وصل می‌شود؟

اولویت NTP دریافتی از DHCP و NTP دستی را بررسی کنید. پارامتر local_time.manual_ntp_srv_prior تعیین می‌کند کدام منبع اولویت بیشتری داشته باشد.

آیا Time Zone اشتباه باعث خرابی TLS می‌شود؟

Certificate بر اساس زمان مطلق اعتبارسنجی می‌شود. Time Zone اشتباه به‌تنهایی الزاماً به معنی Clock مطلق اشتباه نیست، اما نمایش زمان اشتباه می‌تواند سرنخی از پیکربندی نادرست باشد. باید زمان واقعی و Sync شدن NTP بررسی شود.

اگر NTP Server با Domain تنظیم شده باشد چه چیزهایی باید بررسی شوند؟

DNS Server تلفن، پاسخ DNS برای نام NTP Server، مسیر UDP 123 و پاسخ خود NTP Server باید بررسی شوند.

از کجا بفهمیم Yealink واقعاً NTP Request می‌فرستد؟

از تلفن Packet Capture بگیرید و در Wireshark فیلتر ntp را وارد کنید. مقصد Request مشخص می‌کند تلفن در عمل از کدام NTP Server استفاده می‌کند.

اگر NTP Request وجود دارد ولی Response نیست چه کنیم؟

Firewall، ACL، Routing، UDP Port 123 و وضعیت NTP Server را بررسی کنید. اگر Server داخل شبکه است، Capture سمت Server نیز بگیرید.

چرا تنظیم دستی ساعت مشکل را فقط موقتاً حل می‌کند؟

چون منبع اصلی زمان هنوز خراب است. بعد از Reboot یا Sync بعدی، تلفن دوباره به NTP یا DHCP برمی‌گردد. راه‌حل دائمی اصلاح NTP، DHCP و DNS است.

جمع‌بندی

وقتی Yealink روی SIP TLS رجیستر نمی‌شود و هم‌زمان ساعت دستگاه اشتباه است، قبل از تغییر Certificate و Account ابتدا مسیر زمان را بررسی کنید. Yealink می‌تواند NTP Server را از تنظیم دستی یا DHCP دریافت کند و DHCP Option 42 مستقیماً می‌تواند آدرس NTP را تعیین کند.

اگر NTP به‌صورت Domain تعریف شده، DNS نیز بخشی از زنجیره است. اگر Request NTP ارسال می‌شود اما Response ندارد، UDP 123، Firewall و Server را بررسی کنید. اگر Option 42 مقصد اشتباه ارائه می‌کند، تلفن ممکن است با وجود NTP دستی صحیح همچنان سراغ Server اشتباه برود.

در نهایت زمان تلفن را با Not Before و Not After Certificate مقایسه کنید و Syslog TLS را کنار Packet Capture قرار دهید. وقتی می‌بینید NTP Sync شکست خورده و بعد از آن خطای Certificate Is Not Yet Valid ثبت شده است، رابطه بین ساعت اشتباه و خرابی TLS دیگر یک حدس نیست؛ زنجیره خطا را مرحله‌به‌مرحله اثبات کرده‌اید.