SSL certificate created via "trust" has an invalid validity period (same day)

Support
1

The SSL certificate created by clicking the “Trust” link has a validity period from 05/31/2025 to 05/31/2025, which means it expires on the same day it is issued.
Today is 06/03/2025, so the certificate is already expired.

Even if I delete the certificate, update Local, and click “Trust” again, the new certificate still shows the same validity period (05/31/2025 to 05/31/2025) in the Windows Certificate Manager.

I’m not using any plugins, and I can reproduce this issue consistently.

Environment

  • Local Version: 9.2.4+6788
  • OS: Windows 11 Home 24H2

Local Logs

{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] Starting MariaDB 10.4.32-MariaDB source revision c4143f909528e3fab0677a28631d10389354c491 as process 12848”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.121Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.130Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: Uses event mutexes”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.131Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: Compressed tables use zlib 1.3”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.131Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: Number of pools: 1”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.132Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: Using SSE2 crc32 instructions”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.132Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: Initializing buffer pool, total size = 32M, instances = 1, chunk size = 32M”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.132Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: Completed initialization of buffer pool”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.133Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=2553437”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.138Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: 128 out of 128 rollback segments are active.”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.291Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.292Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: Creating shared tablespace for temporary tables”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.292Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: Setting file ‘.\ibtmp1’ size to 12 MB. Physically writing the file full; Please wait …”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.293Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: File ‘.\ibtmp1’ size is now 12 MB.”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.294Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: Waiting for purge to start”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.294Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: 10.4.32 started; log sequence number 2553446; transaction id 1072”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.352Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: Loading buffer pool(s) from %%userDataPath%%\run\gNS6geoIt\mariadb\data\ib_buffer_pool”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.352Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] Plugin ‘FEEDBACK’ is disabled.”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.353Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] Server socket created on IP: ‘127.0.0.1’.”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.355Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] InnoDB: Buffer pool(s) load completed at 250603 20:33:16”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.358Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] Reading of all Master_info entries succeeded”,“process”:“mariadb”,“thread”:“main”,“timestamp”:“2025-06-03T11:33:16.385Z”}
{“class”:“Process”,“level”:“warn”,“message”:“2025-06-03 20:33:16 0 [Note] Added new Master_info ‘’ to hash table”,“process”:“mariadb”,“thread”:“main”,“timestamp”:"2025-06-03T11:33:16.38

Thank you

2

Thanks for the report, @toquetaque. I can’t reproduce this so far with Local 9.2.4 and Windows 11.

I see a cert expiring 10 years from now in 2035 after clicking ‘trust’ (screenshot below).

Could you double-check that your system date, time, and timezone are set correctly? Then delete the current cert, restart your machine, and try again?

image
image653×752 20 KB

3

Thank you for the reply, @nickc

Today, after launching Local and checking the certificate’s validity period, I found that it now correctly spans 10 years: 2025/5/31 – 2035/5/31. Although I’m not sure why, the issue seems to have resolved itself, and SSL connections are now working properly.

My system clock has been synchronized with the time server time.windows.com for a long time, and no changes were made to either the system or Local settings since yesterday.

Yesterday (June 3), the certificate generated by Local had a validity period of only one day: 2025/5/31 – 2025/5/31, which caused SSL connections to fail. At that point, I stopped and exited the Local server.

When I restarted Local today (June 4), I noticed that the certificate had either been regenerated or automatically corrected, now showing a proper 10-year validity period. Unfortunately, I couldn’t find any logs or hints to explain why or how it got fixed.

Interestingly, certificates created before the issue occurred (e.g., 2025/5/27 – 2035/5/27) were already correctly issued from the start.

The fact that the new certificate’s start date is backdated to May 31 (rather than June 3, when the problem occurred) seems a bit odd—even when considering possible time zone differences—but everything is working fine now.

Just wanted to report the situation. If any additional information is needed, please feel free to ask.

Thank you for providing such an excellent development environment with Local.

2 Likes
4

Thank you for following up and sharing these details with us @toquetaque! Hopefully no further issues but keep us posted if anything should change.

1 Like