Custom SSL Certificate Not Applied on Nx Media Server 6.1.0.42176
AnsweredWe are experiencing an issue with the SSL certificate configuration on our Nx Media Server and would appreciate your assistance.
Environment:
- Current Nx Server Version: 6.1.0.42176
-
Certificate File:
.crt
Reference Documentation:
https://support.networkoptix.com/hc/en-us/articles/16635062678039
Issue Description:
Following the instructions in the reference article, we performed the following steps on our Windows Server:
- Double-clicked the
.crtcertificate file. - Selected Current User as the certificate store location.
- Selected Trusted Root Certification Authorities as the certificate store.
- Confirmed the security warning by clicking Yes.
- Restarted the server.
However, after completing these steps, we checked the General tab in the Nx Server interface and found that the server was still using its default self-signed certificate. The certificate we installed does not appear to have been applied.
Questions:
- Are the steps described in the reference article intended only to establish trust for the certificate, rather than to replace the SSL certificate used by the Nx Media Server?
- If we need to replace the default self-signed certificate, what additional configuration steps are required for Nx Server version 6.1.0.42176 on Windows Server?
- Are there any specific requirements for the certificate file format, private key, certificate installation path, or server restart procedure?
Could you please advise us on the correct procedure to configure the certificate so that it is properly applied to the Nx Media Server?
Thank you for your support. We look forward to your guidance.
-
Hi Reeve,
My first thought is, your mediaserver still has the old cert.pem.
What's in your
C:\Windows\System32\config\systemprofile\AppData\Local\<%VENDOR.NAME%>\<%VENDOR.NAME%> Media Server\sslfolder?If you still have both the old and new one in that folder, I suggest moving the old one even if the name isn't the same.
If that's not the case, you may want to attach the server's logs.
Left click Tray assistant icon in the Taskbar > Show Server Log0 -
Hi Mohammed, thank you for your assistance.
I have already tried deleting the
default.pemfile and restarting the Nx Media Server service. However, thedefault.pemfile is automatically regenerated after the service restarts, and the server continues to use the default self-signed certificate.Could you please help investigate why the default certificate is being regenerated and advise me on how to correctly apply our custom certificate?
I couldn't find a place to upload logs. But I used GPT to consolidate the info and hopefully it helps:
Nx Witness Media Server — Log Analysis Summary ================================================= SOURCE FILE: main.log (24,684 lines / 3.9 MB) LOG WINDOW: 2026-10-13 09:56:09 to 2026-10-14 10:07:06 (approx. 24 h; the log begins mid-session - the server was already running when the window opens) PREPARED: 2026-10-14 PURPOSE: Key findings extracted from a high-volume log with extensive duplicate messages, condensed for vendor (US) support review. 1. SERVER & ENVIRONMENT ----------------------- Product : Network Optix Media Server (Nx Witness) Version : 6.1.0.42176 (revision b58aeb045465) OS / account : Windows, service runs under systemprofile (Local System account) Virtualization : VMware VM (vmxnet3 Ethernet adapter) Server HWID : 66357130-efb9-f58c-ea48-2b889534cc8e Log file : C:/Windows/system32/config/systemprofile/AppData/Local/Network Optix/Network Optix Media Server/log/main.log Log config : 10 MB per file / 250 MB volume, level: info Storage : d:/HD Witness Media/... 2nd server in system: 831e12e8-e8b7-2358-c73c-20389ec80889 @ https://vmscntj006:7001 Cameras seen : Axis (rtsp://10.95.188-190.x/axis-media/media.amp), Hikvision B310/B410 (ONVIF), Uniview and others Load before restart (10-14 09:46): OS CPU 54.2% / server process CPU 34.9%; OS memory 56.8% (10-13 10:16) 2. SEVERITY OVERVIEW (after deduplication) ------------------------------------------ WARNING : 20,983 lines (85.0%) INFO : 3,698 lines (15.0%) ERROR : 3 lines (~0.01%) The 20,983 WARNING lines reduce to 10 distinct message classes (see section 4). The 3 ERROR lines are the most important part of this log (section 3). 3. CRITICAL EVENT — SERVER RESTART ON 2026-10-14 ~10:06 (crash + certificate failure) ------------------------------------------------------------------------------------- TIMELINE (all times local): - 2026-10-13 09:56:09 Log window begins (server already running) - ~2026-10-14 10:05:03 Shutdown initiated (inferred - see notes) - 2026-10-14 10:05:18 Recordings stopped for all cameras (graceful shutdown sequence) - 2026-10-14 10:05:58.859 ERROR - CRASH: ASSERTION FAILED at media_server_process.cpp:1442: "Server was unable to stop within 55s" - 2026-10-14 10:06:31.475 Media Server restarted, version 6.1.0.42176 - 2026-10-14 10:06:44.876 Crash dump mediaserver.exe_6.1.0.42176-b58aeb045465-default_12860.dmp uploaded to https://crashes.vmsproxy.com/crashserver/api/report - 2026-10-14 10:06:44.937 ERROR - SSL: "Failed to read private key from PEM"; cert.pem could not be parsed - 2026-10-14 10:06:44.952 Server certificate auto-restored from backup default_20260723_092530_031.pem (backup dated 2026-07-23) - 2026-10-14 10:07:06 Log window ends (cameras reconnecting, streaming resuming) EXACT LOG LINES: 2026-10-14 10:05:58.859 1c04 ERROR CRASH: ASSERTION FAILED: C:\P\573cb5b5af\nx_vms\vms\server\nx_vms_server\src\media_server_process.cpp:1442 (false) Server was unable to stop within 55s 2026-10-14 10:06:31.475 37b4 INFO START: Network Optix Media Server started, version: 6.1.0.42176, revision: b58aeb045465 2026-10-14 10:06:44.876 cf8 INFO ec2::CrashReporter(0x1ce15de0920): Send C:/.../mediaserver.exe_6.1.0.42176-b58aeb045465-default_12860.dmp to https://crashes.vmsproxy.com/crashserver/api/report 2026-10-14 10:06:44.937 37b4 ERROR nx::network::ssl::Certificate: Failed to read private key from PEM. 2026-10-14 10:06:44.937 37b4 ERROR nx::vms::server::SystemCertificate::CertificateInfo(0x2ee0eff280): Failed to parse certificate from file 'C:/.../ssl/cert.pem': Failed to read private key from PEM. 2026-10-14 10:06:44.952 37b4 WARNING nx::vms::server::SystemCertificate(0x1ce15d0f2c0): Restore certificate for Server {66357130-efb9-f58c-ea48-2b889534cc8e} from backup C:/.../backup/ssl/default_20260723_092530_031.pem FACTS vs. INFERENCE: - Fact: a stop was requested, all recordings stopped at 10:05:18, and the process still had not stopped 55 s later -> assertion + crash dump. - Inferred: the stop request was at ~10:05:03 (55 s before the assertion). The log does not record who/what requested the stop (planned restart, update, or crash-driven). - Fact: after restart, cert.pem's private key was unreadable and default.pem was missing; the server restored a certificate from a backup created 2026-07-23 and completed SSL init with it. - Unknown: the root cause of the cert.pem corruption. 4. DEDUPLICATED WARNING INVENTORY (20,983 lines -> 10 classes) -------------------------------------------------------------- W1. rules::Ec2Router - "Unexpected action received: textOverlay (7,351) / enterFullscreen (6,898) / exitFullscreen (317)" Count: 14,566 | Window: whole window | 59% of all warnings Log flood. Rule engine receives actions it does not expect - typically a client or rule/action misconfiguration. W2. onvif::PtzController - "Wrong PTZ type. Only DevicePtzCoordinateSpace is supported" Count: 3,618 | Window: 10-13 10:20 to 10-14 09:29 PTZ position polling incompatible with the cameras' PTZ type. W3. onvif::PtzController - "Zero value of Zoom is received" Count: 2,037 | Window: same as W2 21 cameras (B310/B410 models) report zoom = 0 on position queries. W4. network::ReverseConnectionManager - "N requested connection from {831e12e8...} were never satisfied" (246) + "Incoming connection was not requested from {831e12e8...}" (144) Count: 390 | Window: 10-13 12:40 to 10-14 09:01 Second server (vmscntj006:7001) unreachable / connection unstable. W5. hikvision::IsapiPtzController - "Only device coordinate PTZ space is supported" Count: 154 | Window: 10-13 21:01 to 10-14 10:06 Hikvision ISAPI PTZ limitation, recurring across devices. W6. metrics::StorageController - "Skip missing resource" Count: 67 | Window: 10-14 10:06:39 (startup) Database references resources that no longer exist. W7. QnRtspConnectionProcessorPrivate / QnRtspDataConsumer - RTSP send() failed, OS code 10035 (WSAEWOULDBLOCK) Count: 23 | Window: 10-13 10:22 to 10-14 06:59 Streaming stalls: 14 sends blocked > 100 s, max 1,072 s (~17.9 min) at 10-14 06:19:15. W8. onvif::Resource - "Failed to synchronize camera clock to match VMS clock" (camera A4-4C-62-5A-D7-B1) Count: 2 | Window: 10-13 23:01 Single camera. W9. time::ServerTimeSyncManager - "Can't read time from server 97a95079-...: Can't establish connection to the remote host" Count: 1 | Window: once Time server briefly unreachable. W10. network::RequestDelegator - "Failed to connect to Server {831e12e8...}" Count: 6 | Window: 10-13 14:36 to 22:35 Same root cause as W4. 5. OTHER OBSERVATIONS (INFO level - mostly normal) -------------------------------------------------- - Recording churn, camera A4-14-37-81-D0-9A_channel=2: 386 stop / 378 start events between 22:23:47 and 22:58:04 on 10-13 (~35 min), both Hi- and Low-quality streams. Indicates stream instability on this camera; may correspond to recording gaps in that period. - Server time sync: 103 INFO entries, correction of ~+/-1.2 s every ~10 min. Worth monitoring (typical for VM clock drift), not an error. - Live cache: 159 x "Enabling Live Cache for secondary stream" - normal. - Backup recording: main + backup recorder start/stop events - normal for a system with backup storage. - Module disconnects: 82 x "Removing connection to module {831e12e8...} by URL https://vmscntj006:7001" - consistent with W4/W10. 6. QUESTIONS FOR SUPPORT ------------------------ 1. CRASH (highest priority): analysis of dump ...default_12860.dmp / assertion at media_server_process.cpp:1442 ("Server was unable to stop within 55s"). Is this a known issue in 6.1.0.42176? What typically prevents mediaserver.exe from stopping within the 55 s timeout? 2. CERTIFICATE: what causes "Failed to read private key from PEM" on cert.pem (with default.pem missing)? Is auto-restore from a ~3-month-old backup the expected recovery path, and are there security implications of running on the restored certificate? 3. RTSP STALLS (W7): are send timeouts up to ~18 min (WSAEWOULDBLOCK) a known client/network pattern? Recommended mitigations (client-side, network, or server tuning)? 4. Ec2Router FLOOD (W1): what generates "Unexpected action received: textOverlay / enterFullscreen / exitFullscreen", and what is the supported way to stop the flood? 5. PTZ WARNINGS (W2/W3/W5): with these camera models (Hikvision B310/B410 via ONVIF/ISAPI), are "Wrong PTZ type / Zero value of Zoom / Only device coordinate PTZ space" expected behavior, or a firmware/configuration issue on the camera side? 7. RECOMMENDED CHECKS ON OUR SIDE (parallel to the support case) ---------------------------------------------------------------- 1. Identify what triggered the 10-14 ~10:05 restart (Windows Event Log, planned maintenance, auto-update) - explains the crash context. 2. Verify connectivity and health of server vmscntj006 (831e12e8-...) - W4/W10 point to it. 3. Review event/action rules and active client sessions for textOverlay / fullscreen actions (W1). 4. Check camera A4-14-37-81-D0-9A stream stability (network path, firmware, PoE) - see section 5. 5. Check firmware on the 21 B310/B410 PTZ cameras and their ONVIF profile support (W2/W3). 6. After the certificate restore, confirm the restored certificate is valid, and monitor cert.pem for recurrence. METHOD NOTE: Counts are exact line counts from main.log after masking pointers/GUIDs/camera names; duplicate and "TOO MANY SIMILAR MESSAGES" suppression lines are included in their class totals. Times are as recorded in the log (local time of the server).
0 -
Hey Reeve,
I can already see few abnormal lines :
SSL: "Failed to read private key from PEM"; cert.pem could not be parsed - 2026-10-14 10:06:44.952 Server certificate auto-restored from backup default_20260723_092530_031.pem2026-10-14 10:06:44.937 37b4 ERROR []: Failed to read private key from PEM.2026-10-14 10:06:44.937 37b4 ERROR []: Failed to parse certificate from file 'C:/.../ssl/cert.pem': Failed to read private key from PEM.2026-10-14 10:06:44.952 37b4 WARNING []: Restore certificate for Server {66357130-efb9-f58c-ea48-2b889534cc8e} from backup C:/.../backup/ssl/default_20260723_092530_031.pem FACTS vs. INFERENCE: - Fact: [...] - Fact: after restart, cert.pem's private key was unreadable and default.pem was missing; the server restored a certificate from a backup created 2026-07-23 and completed SSL init with it. - Unknown: the root cause of the cert.pem corruption.It sounds like the mediaserver can't find the private key in the .pem file. Either because the file itself isn't present (unlikely), or its content isn't what the mediaserver expects. Which then causes it to go find a backup .pem and restore it hence why you keep seeing the default cert
Two things I'd like to know:
1. What's the content of your .pem file (The one you generated)? Is it :
-----BEGIN CERTIFICATE-----[CERTIFICATE]-----END CERTIFICATE----------BEGIN PRIVATE KEY-----[PRIVATE KEY]-----END PRIVATE KEY-----2. Is this a self-signed certificate?
Mohammed
0 -
Hi, this is the content:
1.
-----BEGIN CERTIFICATE-----
MIIGwDCCBKigAwIBAgIUUptRShRwSyLp99KCJ3kzK0rBceAwDQYJKoZIhvcNAQEL
BQAwZzELMAkGA1UEBhMCREsxFTATBgNVBAoTDE5vdm8gTm9yZGlzazEYMBYGA1UE
CxMPTm92byBOb3JkaXNrIElUMScwJQYDVQQDEx5Ob3ZvIE5vcmRpc2sgUlNBIElz
c3VpbmcgQ0EgMDMwHhcNMjYwOTIxMDUwMTM2WhcNMjcxMDIxMDUwMTM2WjBKMQsw
CQYDVQQGEwJDTjEUMBIGA1UECgwLTm92b25vcmRpc2sxJTAjBgNVBAMMHHZtc2Nu
dGowMTMuY29ycC5ub3ZvY29ycC5uZXQwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw
ggIKAoICAQDYn8qh9Kwn9xkm7KdtuIh51P+KK3v/EOcDyWM/XzMDhZwmR2ajCH/m
NQxjU86BNwTNqgLNRAsmCsZClX+zMhFFhDrzdWqQIdx9jk7bTrvYvJk5IBfb5si5
jxwmQTlQJ5V98G3FLfjit4qaHmmo078Nxpq7ftRnckT4Mqfdfaivl451OlX0gDGk
UP1pBueFQzio/i5R4V4ulFMJs+IVgkoXDi+CFA2psTtN/kkPo6TA27tXAlwpQCsg
kQdJHq1ctu+Fu8DZm3iGFMkFe5YwL0YtaSvWgppHEAIdAHLK9GVsd1FlXQmlym67
zQSuIaZjJTDf7/LY4EtTJyhXtmZ0P554JpfntjWflGn5nccT20jwFJ0uDEeX5If6
vCBre0Fe8zzK6nmKDYmND8zs60kDdrRzetB+Qz9FhR5sMgu2vQIDsvPT23DqTVVU
PvWZBNvreaA3vN6r2TmndNa8Sh3XSiKk8UCYuXiwmCP8pN9pDXGbBXx5zZJlkIYB
syfn/NgHycsB5A0nmXbR3TCpxvE9ZHeS/zKcwqi+i9DL2dhTATj/Wc8Z4Bpo3RwB
IlTuJIFEKAyoLoiqf1M17G8Mq685PyTiyDPy/AOd4StN7CZHdTOxi3KVWG/hDh+9
uEM1sL8Am6SZC3kPklUx1fmHAk4O8f4R3zunA4CGM5QhlQTAguY0CQIDAQABo4IB
fzCCAXswDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBT8s7znsYA9mNDYHTD5cnr7
RayH2zCBhAYIKwYBBQUHAQEEeDB2MEcGCCsGAQUFBzAChjtodHRwOi8vYWlhLnBr
aS5ub3Zvbm9yZGlzay5jb20vTm92b05vcmRpc2tSU0FJc3N1aW5nQ0EzLmNydDAr
BggrBgEFBQcwAYYfaHR0cDovL29jc3AucGtpLm5vdm9ub3JkaXNrLmNvbTAnBgNV
HREEIDAeghx2bXNjbnRqMDEzLmNvcnAubm92b2NvcnAubmV0MB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDATBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY2Rw
LnBraS5ub3Zvbm9yZGlzay5jb20vTm92b05vcmRpc2tSU0FJc3N1aW5nQ0EzLmNy
bDAdBgNVHQ4EFgQU/bHlKwj+hFGxPL14OijPjOTJ1U8wDgYDVR0PAQH/BAQDAgWg
MA0GCSqGSIb3DQEBCwUAA4ICAQBkEK74u70cqnDjd9iT5XViIw4QIm2zk18xkD4N
I1bo8nSBEyX+Apy/P+EJX1lU0pOkSRBRmG5S8qrfSLp8kKEGMZBSckPOdMVoTPgA
QDQ+udlrBjFf3DCx7YWpndi0UYSj/kqIp715WK1O7Vzrtt2g5OE49aKd58iRH1nN
RumP0huXwWbfVAl1/NJiZX5RHuE3+YdiFOcVqooLLR9WxewxmomvN/ufSI5pCwrU
XUrv0VbXdtcRS/sXc11UssbN2nIfMNGFnoQd3xOZ0DldGwwbKYJL9El7mV65eDjm
62Vf+r+nTm75ru/1+9mcSKvgW5eJhSmKmsm34pFwKFUr4EUfdxkMzV4jvaHwzjB1
0vu1QpzMSbj4rES2PC+zdQygQxROiZ1pJ3MUEzSPS9udBWpbCbNefGoIyzRCLtqK
vqB3sYCeCf/Znm8DPUBRHzH2txFshpvZPDAEIfeanGY7MduJdLIyWmZqYwhvrcj6
ph9zenldqfLd+hmvIXEbuUx4/uaXtX3WjvCIyQl40wU9tK8nkIk0FOpVkL4WxgJX
ZNMtk8nDt4tiw/34FDQJaGL4bcUsp+5fO8q7279+wQ/beYAaHYmfmKkKVFNdz7s8
jSYlaOMYNJYNwcAfBOZlPO6jch2vB7NZKIAotNX63z24xfKtlMLN2+P8WLkbvJFU
9eJBhA==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIG4zCCBMugAwIBAgITcwAAAAfISkv9K/YpBQAAAAAABzANBgkqhkiG9w0BAQsF
ADBlMRgwFgYDVQQLEw9Ob3ZvIE5vcmRpc2sgSVQxCzAJBgNVBAYTAkRLMRUwEwYD
VQQKEwxOb3ZvIE5vcmRpc2sxJTAjBgNVBAMTHE5vdm8gTm9yZGlzayBSU0EgUm9v
dENBIDIwMjQwHhcNMjQwNTA4MDg1MzAzWhcNMzQwNTA4MDkwMzAzWjBnMQswCQYD
VQQGEwJESzEVMBMGA1UEChMMTm92byBOb3JkaXNrMRgwFgYDVQQLEw9Ob3ZvIE5v
cmRpc2sgSVQxJzAlBgNVBAMTHk5vdm8gTm9yZGlzayBSU0EgSXNzdWluZyBDQSAw
MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANliXZhUob3W2Xknct+W
+yeBxcXRCNmlZpaMSw3XMW6YIhS21avNfqYliiNGvRDcq0bsMhlAl0yvbsuDWX5G
x8wA/vu+JjBVdO5xThXYqR6i1dNuJnPtXGrTc3NlryVHy2PLuWlbB7CoG+wnk3Mz
Oc9Y5ElRMExmA8w+dMfvvFo3umWRpR3YIwS5jZ3D93SJRHVJSVYfdm7OUGyyHq+B
1m9VSgBRax5zWl7NmVhPr+BUVjOOr/HWxrC5XatejE6QKyDNKY1cHR2gbw8/S09q
BsdbuU9fIfWS5ehzbUsGys/vo4XNwoBNBKDQq/rdJFeuKFNmNlvyav/ZA8JZk6Qp
oXJHmbqCOyiRFG0wdHanee/ExUBfWDslP3vNxS5DLwvMVdfBc46n2ZmKXi2/aoSH
WaYVLtVI/YZVh0G27sPpqgfkIf/T5RiJ9Hx4Aff7cXOnWXVcklwFilyOJsER/Xwg
8SN8gqfT8jD81hngWDz1e1zWyu2BTNITjGschBju+UnDxHxZyTdH0K6+3jmRelhs
aj37TqTNE6itudnQjOOdC56FNYNHaN7NLyIXy/mkP5hM1I1WbDXniOKAaGa4DXir
SAT+fcPWfx3Xc+IrUGVtIJx3Id3yXikGdbfjaktFX9Db/JxkLJlsLG0mn6zMIrJA
M+sM/NKVgvrjtdG75mUJzOxJAgMBAAGjggGIMIIBhDAdBgNVHQ4EFgQU/LO857GA
PZjQ2B0w+XJ6+0Wsh9swHwYDVR0jBBgwFoAUUruf0IfaYilAyDAXoHqBmpa7b4cw
gYIGA1UdHwR7MHkwd6B1oHOGN2h0dHA6Ly9wa2kubm92b25vcmRpc2suY29tL05v
dm9Ob3JkaXNrUlNBUm9vdENBMjAyNC5jcmyGOGh0dHA6Ly9jZHAxLm5vdm9ub3Jk
aXNrLmNvbS9Ob3ZvTm9yZGlza1JTQVJvb3RDQTIwMjQuY3JsMIGbBggrBgEFBQcB
AQSBjjCBizBDBggrBgEFBQcwAoY3aHR0cDovL3BraS5ub3Zvbm9yZGlzay5jb20v
Tm92b05vcmRpc2tSU0FSb290Q0EyMDI0LmNydDBEBggrBgEFBQcwAoY4aHR0cDov
L2FpYTEubm92b25vcmRpc2suY29tL05vdm9Ob3JkaXNrUlNBUm9vdENBMjAyNC5j
cnQwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAYYwDQYJKoZIhvcNAQEL
BQADggIBACHlfTD0xT20qB0zVUM4p14IMwMn8qQG2bV0FCk5SUEM5UmHyvUYh3yC
H4VL69DfcVffLsjV3KH7zrqSAOSyEKHSQG0T9t83OqlG95MsIk8hnNc+5XUpwC/6
RQrG/BpifOzptdERh3+lbKqjMcAEtubsLVjLeEX7eyOD7x4peBr6JFtxRy9l0Zwa
x5uvbjubC8WMrlp0yX8RiKJrCaxQrEd48Yuk4jpL7BrtJGY4S0YnQQBXY0PcfN1a
WOhQ8gJKP2XL5r6by3aYg81TWx+rfkDu7oFIsV+ExANRikAJfs7gSBEDoSPMGVwu
BE66siXlsmvgoEAhtQZ7DTaNnrPp1wxl1jplyEw/RvV3KAScnHtJyK4yhoez6sKh
4PuzJ7lx3F5zT3T/4n9UDfAL1Nj5iNa3k6dZrvGgcklAVjykBGu94/EKgxBOsvKN
ezHOcpprzIotmfAlguyxzDWr3dK2+8t7c99ZrySASG5ev78vasHaGLE/5hKIiFpf
AGBx6ljHFZiYCqnrwlln6wJDncUXiqAqyhocldyY7eOAVNt3oXfpD9C9Xa3xhXnU
TMD8BhleyZYewGOyeWO4o8s6mFmW4KsiGWrn2AiX+zLWlcF4mXxZuBwW9Lps3V0A
AR8W6TWxwhDhl3W7k/GxE27QuodTeLodTyogbIdEIJ1tB6zM3aNn
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFpTCCA42gAwIBAgIQVOFmrfnWb6NHfv7VeKuYHjANBgkqhkiG9w0BAQsFADBl
MRgwFgYDVQQLEw9Ob3ZvIE5vcmRpc2sgSVQxCzAJBgNVBAYTAkRLMRUwEwYDVQQK
EwxOb3ZvIE5vcmRpc2sxJTAjBgNVBAMTHE5vdm8gTm9yZGlzayBSU0EgUm9vdENB
IDIwMjQwHhcNMjQwNTAxMDk1MDIyWhcNNDQwNTAxMDk1MDIyWjBlMRgwFgYDVQQL
Ew9Ob3ZvIE5vcmRpc2sgSVQxCzAJBgNVBAYTAkRLMRUwEwYDVQQKEwxOb3ZvIE5v
cmRpc2sxJTAjBgNVBAMTHE5vdm8gTm9yZGlzayBSU0EgUm9vdENBIDIwMjQwggIi
MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDOh23vQdvWnUTN212KksU7BewA
GcMC5PHo7xcMSEPgfxHJDlwUP4tMBWE8PvGvaaZ5M4VlbFuZwnJhPgBYzgSVlKe/
Hhy+mGRGeISJWDaKxglDra5UdEOURurkQec1or3eHjGxw7auWfAOM6PNWaQflVHm
sx1lchCv4p+GkV1hBkycZw+/m3U4gTeJaOFdev62yQ8EWEsYgDeUDHoxwdOEp2+Z
iaqOJzpgofm43fFVAKXByFNqN70KzIKje3IThrGcw+jA1O0sIzLrsW8otDUtKxN8
07eqIH4RpbjkqJ9rn8mjX/H42f68wo+2ewW5AIcqdnKcFwM3vPLtmr9SV5FzFkL3
kPrxZuOwb+WiCV3jJLbEFhykXQZ/k1ssOTASXwSlHw7ZJFTGrt/yGTcxaJXN5VRG
ZEJGsFHH7+VUsoMpc5lyeRfwv8DdQmu31bmUd30wBf73pLPrtUKZLz+e/L28Wu2o
cVYEvcuKPybqw/CuJZJgUYjff896QHZLCh/ipeY2yLeO3WsCr/HgcJF/wqvXuO8i
afffT0Ov8AlKOnWgJITUeeidqClMAgczjnisuUh3sBJq1TGViVMA+j8cX5ZaSK36
Klcujk8Wx+ADoRQAyQNCeBWrWWJC58Xw0JysWmwJPXpZW0VJEnTecO62s2qZ9SqP
S/kt2gSMe94hZvlLPQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUw
AwEB/zAdBgNVHQ4EFgQUUruf0IfaYilAyDAXoHqBmpa7b4cwEAYJKwYBBAGCNxUB
BAMCAQAwDQYJKoZIhvcNAQELBQADggIBAC86/lGEr0lG0eNgOVeUz/r1SjWFxsyB
7Vz1wNuJWyW+NR23sOfbK0LBGsl+l2B0ow9lYnmaWCO0vu6fjzhsF8qlHd294olq
MEAa0FxlSfAixV3YoNHdZyFhmdrF/oITXKRLsOoBXsHQBDCCxa0byYu1VvbL4J7J
j9ccn5OP7NC3qJKMYe1IlDNlQYmEk8v9cGFxCmDPDdWvXK3+5zEaRrxy+l8+F25X
vKglekcrpkkLaiDCC29et72oq8IsBuCmkGZTqBluxR0YZr7b1BlA/X75XMegdagu
nFik7hRKvLe0r4NGsuGDPNeqRQPF0ucVW/GyVS3/7fS6mCfwQ5IksH7kYvtvVlz2
b+1ceN7zHl7qquogZq/MIOnSeJYnFlUnmOnTe1OiGJqLNHbEtvStXhDp2kPG2KTS
EfZXpGIfWdC2bsr6paGYXKQHegtFj2nWGMF1ZuM+mP14BD+2k10f9yzzdU4DRtSW
RV4s/CJnfDYd2/FY0bOIienl0ZDDoBHZLp8E4SbYeInuqDJqtxtd39aI/WoJDE78
xN8enL4opx5anL0X3LN42q+hMdYV9AjsLEdm2z2zuohRguJgZ1xoakuDR3HEbJT3
Xu8Xt4TwpZy2HnG5eJcORh1To2y/kBfCkzapwCKor/FVEKhIUlDn6FNcaT3YiIQz
6R00O0lQX36M
-----END CERTIFICATE-----2. Nope, it is assigned by the company's DNS
0 -
Hi,
You're missing the private key in your .pem file. It should be formatted as follows:
-----BEGIN PRIVATE KEY----- ... Private key content ... -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- ... Server certificate content ... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- ... Intermediate CA content ... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- ... Root CA content ... -----END CERTIFICATE-----0
Please sign in to leave a comment.
Comments
5 comments