Failed to start VNC server: The server certificate /etc/pve/local/pve-ssl.pem is not yet active

I

iscrow

Renowned Member
Dec 10, 2009
10
14
68
Brand new install of PVE 4.1. Did an upgrade and dist-upgrade. Can't start any VMs. All I get is:

Running as unit 100.scope.
kvm: -vnc unix:/var/run/qemu-server/100.vnc,x509,password: Failed to start VNC server: The server certificate /etc/pve/local/pve-ssl.pem is not yet active

Here's my version info:
proxmox-ve: 4.1-37 (running kernel: 4.2.8-1-pve)
pve-manager: 4.1-13 (running version: 4.1-13/cfb599fb)
pve-kernel-4.2.6-1-pve: 4.2.6-36
pve-kernel-4.2.8-1-pve: 4.2.8-37
lvm2: 2.02.116-pve2
corosync-pve: 2.3.5-2
libqb0: 1.0-1
pve-cluster: 4.0-32
qemu-server: 4.0-55
pve-firmware: 1.1-7
libpve-common-perl: 4.0-48
libpve-access-control: 4.0-11
libpve-storage-perl: 4.0-40
pve-libspice-server1: 0.12.5-2
vncterm: 1.2-1
pve-qemu-kvm: 2.5-5
pve-container: 1.0-44
pve-firewall: 2.0-17
pve-ha-manager: 1.0-21
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u1
lxc-pve: 1.1.5-7
lxcfs: 0.13-pve3
cgmanager: 0.39-pve1
criu: 1.6.0-1
zfsutils: 0.6.5-pve7~jessie

If anyone can give me any ideas, I'd really appreciate it! Thank you!
 
Does the file /etc/pve/local/pve-ssl.pem exist? You can regenerate the ssl certificate for a node by running "pvecm updatecerts -f" (note that although this command is part of pvecm, it only works locally on the node where it is executed!).
 
Fabian, thanks for responding!

The file did exist. I checked that immediately. I kept trying to bring the VM up on and off for about 4 hours. No luck. There was a similar report here https://forum.proxmox.com/threads/f...ve-local-pve-ssl-pem-is-not-yet-active.26004/ and later the original poster followed up saying it's working for them. So what do you know, a few hours later (overnight) I tried again and all is well. No errors, no problem. I'm up.

Do you think I should mark this thread as solved? There still is an issue, I just can't duplicate it now. Any other ideas as to what I should check or what info to collect while the problem is occurring on my next proxmox install? For me the problem persisted for about 7 hrs, then bunch of things happened on the system (in daemon.log) and all is well!

Here's the interesting bit. At 4:28am (almost 7hrs after the install) in daemon.log I see the following:
(So the questions is why did all this happen with this 7hr delay after install? Any ideas?)

Code: 
Feb 16 04:28:01 vhostmc systemd-modules-load[279]: Module 'fuse' is builtin
Feb 16 04:28:01 vhostmc systemd-modules-load[279]: Inserted module 'vhost_net'
Feb 16 04:28:01 vhostmc hdparm[305]: Setting parameters of disc: (none).
Feb 16 04:28:01 vhostmc keyboard-setup[304]: Setting preliminary keymap...done.
Feb 16 04:28:01 vhostmc lvm[514]: 3 logical volume(s) in volume group "pve" now active
Feb 16 04:28:01 vhostmc systemd-fsck[538]: /dev/mapper/pve-data: clean, 18/112721920 files, 7124896/450860032 blocks
Feb 16 04:28:01 vhostmc zpool[632]: no pools available to import
Feb 16 04:28:01 vhostmc lvm[536]: 3 logical volume(s) in volume group "pve" now active
Feb 16 04:28:01 vhostmc lvm[644]: 3 logical volume(s) in volume group "pve" monitored
Feb 16 04:28:01 vhostmc mv[652]: /bin/mv: cannot stat ‘/etc/network/interfaces.new’: No such file or directory
Feb 16 04:28:01 vhostmc pvepw-logger[676]: starting pvefw logger
Feb 16 04:28:01 vhostmc networking[651]: Configuring network interfaces...
Feb 16 04:28:01 vhostmc networking[651]: Waiting for vmbr0 to get ready (MAXWAIT is 2 seconds).
Feb 16 04:28:01 vhostmc networking[651]: done.
Feb 16 04:28:01 vhostmc iscsid: iSCSI logger with pid=881 started!
Feb 16 04:28:01 vhostmc open-iscsi[853]: Starting iSCSI initiator service: iscsid.
Feb 16 04:28:01 vhostmc open-iscsi[853]: Setting up iSCSI targets:
Feb 16 04:28:01 vhostmc open-iscsi[853]: iscsiadm: No records found
Feb 16 04:28:01 vhostmc open-iscsi[853]: .
Feb 16 04:28:01 vhostmc rpcbind[854]: Starting rpcbind daemon....
Feb 16 04:28:01 vhostmc open-iscsi[853]: Mounting network filesystems:.
Feb 16 04:28:01 vhostmc open-iscsi[853]: Enabling network swap devices:.
Feb 16 04:28:01 vhostmc kbd[895]: Setting console screen modes.
Feb 16 04:28:01 vhostmc rpc.statd[929]: Version 1.2.8 starting
Feb 16 04:28:01 vhostmc sm-notify[931]: Version 1.2.8 starting
Feb 16 04:28:01 vhostmc rpc.statd[929]: Failed to read /var/lib/nfs/state: Success
Feb 16 04:28:01 vhostmc rpc.statd[929]: Initializing NSM state
Feb 16 04:28:01 vhostmc kbd[895]: setterm: $TERM is not defined.
Feb 16 04:28:01 vhostmc nfs-common[892]: Starting NFS common utilities: statd idmapd.
Feb 16 04:28:01 vhostmc console-setup[946]: Setting up console font and keymap.../usr/bin/ckbcomp: Can not find file "symbols/en-us" in any known directory
Feb 16 04:28:01 vhostmc console-setup[946]: failed.
Feb 16 04:28:01 vhostmc apparmor[896]: Starting AppArmor profiles:.
Feb 16 04:28:01 vhostmc rm[984]: /bin/rm: cannot remove ‘/etc/dfs/sharetab’: No such file or directory
Feb 16 04:28:01 vhostmc zed[985]: ZFS Event Daemon 0.6.5-pve6~jessie (PID 985)
Feb 16 04:28:01 vhostmc zed[985]: Processing events since eid=0
Feb 16 04:28:01 vhostmc lxcfs[989]: hierarchies: 1: name=systemd
Feb 16 04:28:01 vhostmc lxcfs[989]: 2: cpuset
Feb 16 04:28:01 vhostmc lxcfs[989]: 3: cpu,cpuacct
Feb 16 04:28:01 vhostmc lxcfs[989]: 4: blkio
Feb 16 04:28:01 vhostmc lxcfs[989]: 5: memory
Feb 16 04:28:01 vhostmc lxcfs[989]: 6: devices
Feb 16 04:28:01 vhostmc lxcfs[989]: 7: freezer
Feb 16 04:28:01 vhostmc lxcfs[989]: 8: net_cls,net_prio
Feb 16 04:28:01 vhostmc lxcfs[989]: 9: perf_event
Feb 16 04:28:01 vhostmc lxcfs[989]: 10: hugetlb
Feb 16 04:28:01 vhostmc watchdog-mux[999]: Watchdog driver 'Software Watchdog', version 0
Feb 16 04:28:01 vhostmc rrdcached[1013]: starting up
Feb 16 04:28:01 vhostmc rrdcached[1013]: checking for journal files
Feb 16 04:28:01 vhostmc rrdcached[1013]: started new journal /var/lib/rrdcached/journal/rrd.journal.1455614881.559698
Feb 16 04:28:01 vhostmc rrdcached[1013]: journal processing complete
Feb 16 04:28:01 vhostmc rrdcached[1013]: listening for connections
Feb 16 04:28:01 vhostmc rrdcached[996]: Starting RRDtool data caching daemon: rrdcached.
Feb 16 04:28:01 vhostmc dbus[1001]: [system] Successfully activated service 'org.freedesktop.systemd1'
Feb 16 04:28:01 vhostmc lxc-devsetup[1046]: Creating /dev/.lxc
Feb 16 04:28:01 vhostmc lxc-devsetup[1046]: /dev is devtmpfs
Feb 16 04:28:01 vhostmc lxc-devsetup[1046]: Creating /dev/.lxc/user
Feb 16 04:28:01 vhostmc postfix[997]: Starting Postfix Mail Transport Agent: postfix.
Feb 16 04:28:01 vhostmc pvecm[1068]: ipcc_send_rec failed: Connection refused
Feb 16 04:28:01 vhostmc pvecm[1068]: ipcc_send_rec failed: Connection refused
Feb 16 04:28:01 vhostmc pvecm[1068]: ipcc_send_rec failed: Connection refused
Feb 16 04:28:02 vhostmc iscsid: iSCSI daemon with pid=882 started!
Feb 16 04:28:02 vhostmc pvecm[1068]: Generating public/private rsa key pair.
Feb 16 04:28:02 vhostmc pvecm[1068]: Your identification has been saved in /root/.ssh/id_rsa.
Feb 16 04:28:02 vhostmc pvecm[1068]: Your public key has been saved in /root/.ssh/id_rsa.pub.
Feb 16 04:28:02 vhostmc pvecm[1068]: The key fingerprint is:
Feb 16 04:28:02 vhostmc pvecm[1068]: 03:ed:54:81:ac:43:47:74:ab:f4:9d:12:87:ff:43:f1 root@vhostmc
Feb 16 04:28:02 vhostmc pvecm[1068]: The key's randomart image is:
Feb 16 04:28:02 vhostmc pvecm[1068]: +---[RSA 2048]----+
Feb 16 04:28:02 vhostmc pvecm[1068]: |.. ... .oo.       |
Feb 16 04:28:02 vhostmc pvecm[1068]: |..+  = .o o      |
Feb 16 04:28:02 vhostmc pvecm[1068]: |ooo.. =  E       |
Feb 16 04:28:02 vhostmc pvecm[1068]: |oo.  = ..  .      |
Feb 16 04:28:02 vhostmc pvecm[1068]: |o.. . = S        |
Feb 16 04:28:02 vhostmc pvecm[1068]: |o  . o oo          |
Feb 16 04:28:02 vhostmc pvecm[1068]: |..                |
Feb 16 04:28:02 vhostmc pvecm[1068]: |                 |
Feb 16 04:28:02 vhostmc pvecm[1068]: |                 |
Feb 16 04:28:02 vhostmc pvecm[1068]: +-----------------+
Feb 16 04:28:03 vhostmc pvestatd[1181]: starting server
Feb 16 04:28:03 vhostmc pve-firewall[1182]: starting server
Feb 16 04:28:03 vhostmc pvedaemon[1193]: starting server
Feb 16 04:28:03 vhostmc pvedaemon[1193]: starting 3 worker(s)
Feb 16 04:28:03 vhostmc pvedaemon[1193]: worker 1194 started
Feb 16 04:28:03 vhostmc pvedaemon[1193]: worker 1195 started
Feb 16 04:28:03 vhostmc pvedaemon[1193]: worker 1196 started
Feb 16 04:28:03 vhostmc pve-ha-crm[1199]: starting server
Feb 16 04:28:03 vhostmc pve-ha-crm[1199]: status change startup => wait_for_quorum
Feb 16 04:28:03 vhostmc pveproxy[1201]: starting server
Feb 16 04:28:03 vhostmc pveproxy[1201]: starting 3 worker(s)
Feb 16 04:28:03 vhostmc pveproxy[1201]: worker 1202 started
Feb 16 04:28:03 vhostmc pveproxy[1201]: worker 1203 started
Feb 16 04:28:03 vhostmc pveproxy[1201]: worker 1205 started
Feb 16 04:28:04 vhostmc pve-ha-lrm[1207]: starting server
Feb 16 04:28:04 vhostmc pve-ha-lrm[1207]: status change startup => wait_for_agent_lock
Feb 16 04:28:04 vhostmc spiceproxy[1208]: starting server
Feb 16 04:28:04 vhostmc spiceproxy[1208]: starting 1 worker(s)
Feb 16 04:28:04 vhostmc spiceproxy[1208]: worker 1209 started
 
Hi,
I'm able to reproduce it too, fresh 4.1 install + last updates.
create a new vm, and start it.

"Failed to start VNC server: The server certificate /etc/pve/local/pve-ssl.pem is not yet active"
server install at

Maybe it's related to timezone

Validity
Not Before: Feb 17 11:10:22 2016 GMT

Current time:

# timedatectl
Local time: Wed 2016-02-17 12:06:46 CET
Universal time: Wed 2016-02-17 11:06:46 UTC
RTC time: Wed 2016-02-17 11:06:46
Time zone: Europe/Paris (CET, +0100)


Code: 
root@proxmoxalex:/etc/pve/local# openssl x509 -in /etc/pve/pve-root-ca.pem -noout -text 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 16473116544837473621 (0xe49c44381ea5d555)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Proxmox Virtual Environment, OU=e2f5df6731d917fc9dd0e45255477840, O=PVE Cluster Manager CA
        Validity
            Not Before: Feb 17 11:10:22 2016 GMT
            Not After : Feb 14 11:10:22 2026 GMT
        Subject: CN=Proxmox Virtual Environment, OU=e2f5df6731d917fc9dd0e45255477840, O=PVE Cluster Manager CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:9e:97:5e:56:02:b9:c3:8e:57:2a:e6:45:ce:0e:
                    2f:3d:c7:d8:88:a2:be:f2:08:2c:15:34:1c:cb:86:
                    0a:a8:42:00:f8:89:20:0b:d7:79:53:ac:0a:99:13:
                    81:a8:2d:49:3a:9b:35:74:5f:1d:4a:99:3b:6d:e8:
                    ea:f5:ac:5e:8f:3f:d4:b4:a7:04:bb:b1:1d:b3:6a:
                    54:dd:6c:5f:5c:76:de:8c:6e:47:21:ff:fb:4e:71:
                    30:84:35:7d:cc:1e:1a:d5:ed:10:c0:b0:0e:5f:91:
                    78:dd:1f:ba:bd:eb:8a:04:05:7f:36:5d:10:dc:cd:
                    7f:cb:c2:fe:18:ad:75:00:99:90:96:2c:16:6a:27:
                    7e:8d:4b:89:d1:28:16:93:36:3b:2b:1e:68:1e:16:
                    80:12:8e:b4:6d:b9:2b:23:5f:98:94:25:02:39:41:
                    ed:93:e8:9d:5f:72:0c:aa:29:3c:df:bd:60:54:0e:
                    29:fd:08:bb:78:05:7b:91:e8:b6:58:b3:50:de:b5:
                    81:9c:2a:43:62:07:16:5e:3f:ff:ac:05:c8:c1:76:
                    1c:1f:73:bf:b8:42:33:7b:13:d8:64:67:eb:02:60:
                    0e:42:e0:07:ea:82:65:32:1a:4f:3e:1a:fd:bf:c0:
                    8d:8c:c5:dc:11:a9:c4:fe:14:1f:a0:58:7f:9a:32:
                    bf:b9
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                7D:40:27:C4:F7:1F:C2:BD:7D:1C:3E:3C:2D:B0:78:AC:03:38:2E:79
            X509v3 Authority Key Identifier: 
                keyid:7D:40:27:C4:F7:1F:C2:BD:7D:1C:3E:3C:2D:B0:78:AC:03:38:2E:79

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption
         43:3c:76:16:d7:d8:6f:9b:55:79:07:ce:a4:19:5d:a2:fe:a9:
         cd:50:3a:b3:33:21:ce:74:e3:30:db:ec:3d:56:71:3d:ac:23:
         59:57:7a:ef:60:2e:32:40:24:53:8b:b8:43:7d:f9:93:f5:d7:
         c1:18:f1:f5:c9:be:12:87:6f:bb:36:75:bd:6c:d6:f5:0a:fb:
         ad:3f:7e:26:b3:44:4e:02:ba:96:85:ae:63:57:07:c5:8c:8f:
         15:fb:20:e8:d5:73:a9:2d:17:8f:6e:9d:c2:d1:e7:46:17:62:
         d9:8f:a8:bb:f5:02:b8:fa:aa:42:15:bf:08:4c:31:a1:78:b8:
         86:80:30:79:af:c7:22:e7:ed:10:ee:dd:13:08:75:bd:e1:ca:
         10:ab:a4:a4:41:ec:08:83:d8:39:a5:95:65:a9:d1:c2:8d:2b:
         94:9b:95:d4:ed:e4:ff:f3:f0:1f:71:be:96:fa:05:3f:63:08:
         31:bd:7e:5f:17:e4:04:8e:07:95:3c:db:99:e7:73:2b:8f:50:
         35:79:30:fe:3f:97:df:fb:2e:5a:b2:91:ae:b9:2d:2c:6f:30:
         cb:e5:f1:97:cc:d3:4d:b3:b5:a2:24:1e:7e:b0:95:cd:50:7c:
         0b:b7:36:60:a8:3b:c0:0b:93:02:dd:b5:e9:62:72:44:3f:fc:
         60:2c:37:92
 
It's working now

# timedatectl
Local time: Wed 2016-02-17 12:11:52 CET
Universal time: Wed 2016-02-17 11:11:52 UTC
RTC time: Wed 2016-02-17 11:11:52
Time zone: Europe/Paris (CET, +0100)

so it's related to timezone
 
I cannot reproduce this at all.. what is your $LANG and $TZ set to?

Do newly created certificates (i.e., with "pvecm updatecerts -f") also show this issue? Or just the first one after a fresh installation? Did you have internet access during the installation?
 
Hello, same error here, but "The CA certificate /etc/pve/pve-root-ca.pem is not yet active".
Fresh install 4.1 + latest updates.

openssl x509 -in /etc/pve/pve-root-ca.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 18303896445522832238 (0xfe0480d6c8ec6b6e)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=Proxmox Virtual Environment, OU=d9346c684ded0499f67c2180bc3875c0, O=PVE Cluster Manager CA
Validity
Not Before: Feb 18 13:51:38 2016 GMT
Not After : Feb 15 13:51:38 2026 GMT
Subject: CN=Proxmox Virtual Environment, OU=d9346c684ded0499f67c2180bc3875c0, O=PVE Cluster Manager CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption

pveversion --verbose
proxmox-ve: 4.1-37 (running kernel: 4.2.8-1-pve)
pve-manager: 4.1-13 (running version: 4.1-13/cfb599fb)
pve-kernel-4.2.6-1-pve: 4.2.6-36
pve-kernel-4.2.8-1-pve: 4.2.8-37
lvm2: 2.02.116-pve2
corosync-pve: 2.3.5-2
libqb0: 1.0-1
pve-cluster: 4.0-32
qemu-server: 4.0-55
pve-firmware: 1.1-7
libpve-common-perl: 4.0-48
libpve-access-control: 4.0-11
libpve-storage-perl: 4.0-40
pve-libspice-server1: 0.12.5-2
vncterm: 1.2-1
pve-qemu-kvm: 2.5-5
pve-container: 1.0-44
pve-firewall: 2.0-17
pve-ha-manager: 1.0-21
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u1
lxc-pve: 1.1.5-7
lxcfs: 0.13-pve3
cgmanager: 0.39-pve1
criu: 1.6.0-1
zfsutils: 0.6.5-pve7~jessie

date
Thu Feb 18 16:35:38 MSK 2016
root@tel-hv06:~# timedatectl
Local time: Thu 2016-02-18 16:35:41 MSK
Universal time: Thu 2016-02-18 13:35:41 UTC
RTC time: Thu 2016-02-18 13:35:41
Time zone: Europe/Moscow (MSK, +0300)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a

qm start 100
Running as unit 100.scope.
kvm: -vnc unix:/var/run/qemu-server/100.vnc,x509,password: Failed to start VNC server: The CA certificate /etc/pve/pve-root-ca.pem is not yet active
 
I just got this bug today. GMT+10 here.

It looks like the Certificate is generated using the Local Time, but NOT adjusting for UTC.

For Example:

It is currently 14:04 GMT +11 (AEDT)
The Certificate validity is "Not Before: 14:04 GMT".

The certificate in my case should be generating for 2:04 GMT.

So depending on how far ahead of GMT you are, is the time you'll have to wait for it to become valid.

Also explains why anyone testing in GMT or behind will not experience this issue. I'm assuming this is a regression though as I've never encountered this until now (fresh 4.1 install).

EDIT:

QUICK WORKAROUND:

-Install with your timezone set to GMT (Europe/London)
-Change timezone in the PVE interface or via /etc/localtime after installation finishes.

or if you're already installed

-Change timezone to GMT (Europe/London) in the web interface
-delete your /etc/pve/pve-root-ca.pem
-run "pvecm updatecerts -f" to create cert package
-Change timezone to your correct timezone

Both methods ensure the certs are created with GMT time in mind.
 
Last edited:
Did you have network/internet access during install? Did you install on bare metal or in some (other) virtualization environment?

Most of the Proxmox developers are in GMT+, not GMT or GMT-, and we have only experienced this issue when installing under a virtualization product that sets the clock in its VMs wrong (i.e., VMs are started with the RTC set to the local time of the host, while the Proxmox installer thinks the RTC is set to GMT and uses that time to generate the certificates).

Could you post the output of "timedatectl"? If you leave your timezone set to GMT+11 and run "pvecm udpatecerts -f", does the newly generated certificate in /etc/pve/local/pve-ssl.pem exhibit the issue or not?
 
I got the same ...
Just installed 4.1 on Baremetal, but with a broken network connection (gave the wrong Gateway).
During Install I set "Germany", so the clock is set to CEST.
Code: 
timedatectl
      Local time: Sun 2016-04-10 11:32:21 CEST
  Universal time: Sun 2016-04-10 09:32:21 UTC
        RTC time: Sun 2016-04-10 09:32:21
       Time zone: Europe/Berlin (CEST, +0200)
     NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
      DST active: yes
Last DST change: DST began at
                  Sun 2016-03-27 01:59:59 CET
                  Sun 2016-03-27 03:00:00 CEST
Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2016-10-30 02:59:59 CEST
                  Sun 2016-10-30 02:00:00 CET

In the Certificate:
Code: 
 openssl x509 -in /etc/pve/pve-root-ca.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 16631829171211481969 (0xe6d02083130a3371)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Proxmox Virtual Environment, OU=7993a4c7574eeb9545889282f4313                                   4e0, O=PVE Cluster Manager CA
        Validity
            Not Before: Apr 10 10:37:58 2016 GMT
            Not After : Apr  8 10:37:58 2026 GMT
        Subject: CN=Proxmox Virtual Environment, OU=7993a4c7574eeb9545889282f431

when i do
Code: 
/etc/pve/local# TZ=GMT date
Sun Apr 10 09:27:32 GMT 2016

i can see, that the clock in GMT is two hours back to the Certificate.
I have to wait (only) one more hour to start my recovered VMs :-(

Does it have to do with the broken network?

When I run "pvecm updatecerts -f" the cert does not change ...
 
Just for the fun :D

Therefore I had to install a second one, I tried it first again without Network, and got the same result like above.
Then i did another install on the same machine, but this time WITH network during install.
Result:
Code: 
root@pve-enm03:~# TZ=GMT date
Sun Apr 10 10:24:25 GMT 2016
root@pve-enm03:~# date
Sun Apr 10 12:24:29 CEST 2016
root@pve-enm03:~# openssl x509 -in /etc/pve/pve-root-ca.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 14439361434425957964 (0xc862eab8ba6f1e4c)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Proxmox Virtual Environment, OU=0656e87d6fa1d3b18522c85e7cdd4                                   7cb, O=PVE Cluster Manager CA
        Validity
            Not Before: Apr 10 10:23:18 2016 GMT
            Not After : Apr  8 10:23:18 2026 GMT
        Subject: CN=Proxmox Virtual Environment, OU=0656e87d6fa1d3b18522c85e7cdd

So, the Problem is NOT SOLVED, but now we know what it is ....
 
This will be fixed when the installer iso is rebuilt, as the problem is caused by a race condition on first boot of a freshly installed node. If you are affected by this and don't want to wait the X hours (depending on your timezone), you can do the following:
Code: 
rm /etc/pve/pve-root-ca.pem /etc/pve/priv/pve-root-ca.key
pvecm updatecerts -f

Which will recreate both the cluster CA and the node certificate and key.
 
  • Like
Reactions: rubi2020
fabian said:
This will be fixed when the installer iso is rebuilt, as the problem is caused by a race condition on first boot of a freshly installed node.
Click to expand...

Just to notify you that I installed (bare metal) 4.2 without internet connection, had problems to identify the right eth0 port so I did some reboot before solving (AFAIR), and had the certificate FAR AWAY from current date/time (I recreated it with your instruction and now everything is ok).
This just to let you know that seems not yet solved.

Code: 
root@prox01:~# qm start 117
Running as unit 117.scope.
kvm: -vnc unix:/var/run/qemu-server/117.vnc,x509,password: Failed to start VNC server: The server certificate /etc/pve/local/pve-ssl.pem is not yet active
and
Code: 
root@prox01:~# timedatectl
  Local time: Tue 2016-05-17 10:46:51 CEST
  Universal time: Tue 2016-05-17 08:46:51 UTC
  RTC time: Tue 2016-05-17 08:46:51
  Time zone: Europe/Rome (CEST, +0200)
  NTP enabled: yes
NTP synchronized: yes 
RTC in local TZ: no 
  DST active: yes 
Last DST change: DST began at 
  Sun 2016-03-27 01:59:59 CET 
  Sun 2016-03-27 03:00:00 CEST 
Next DST change: DST ends (the clock jumps one hour backwards) at 
  Sun 2016-10-30 02:59:59 CEST 
  Sun 2016-10-30 02:00:00 CET
and the certificate was (as you can see, not before Dec 8 2016!)
Code: 
root@prox01:~# openssl x509 -in /etc/pve/pve-root-ca.pem -noout -text 
Certificate:
  Data:
  Version: 3 (0x2)
  Serial Number: 13706215231112316391 (0xbe364222517f85e7)
  Signature Algorithm: sha256WithRSAEncryption
  Issuer: CN=Proxmox Virtual Environment, OU=834ad1c6be0653aa2bca465961757fe6, O=PVE Cluster Manager CA
  Validity
  Not Before: Dec  8 09:50:45 2016 GMT
  Not After : Dec  6 09:50:45 2026 GMT
  Subject: CN=Proxmox Virtual Environment, OU=834ad1c6be0653aa2bca465961757fe6, O=PVE Cluster Manager CA

Best regards
Marco Menardi
 
mmenaz said:
Just to notify you that I installed (bare metal) 4.2 without internet connection, had problems to identify the right eth0 port so I did some reboot before solving (AFAIR), and had the certificate FAR AWAY from current date/time (I recreated it with your instruction and now everything is ok).
This just to let you know that seems not yet solved.

Code: 
root@prox01:~# qm start 117
Running as unit 117.scope.
kvm: -vnc unix:/var/run/qemu-server/117.vnc,x509,password: Failed to start VNC server: The server certificate /etc/pve/local/pve-ssl.pem is not yet active
and
Code: 
root@prox01:~# timedatectl
  Local time: Tue 2016-05-17 10:46:51 CEST
  Universal time: Tue 2016-05-17 08:46:51 UTC
  RTC time: Tue 2016-05-17 08:46:51
  Time zone: Europe/Rome (CEST, +0200)
  NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
  DST active: yes
Last DST change: DST began at
  Sun 2016-03-27 01:59:59 CET
  Sun 2016-03-27 03:00:00 CEST
Next DST change: DST ends (the clock jumps one hour backwards) at
  Sun 2016-10-30 02:59:59 CEST
  Sun 2016-10-30 02:00:00 CET
and the certificate was (as you can see, not before Dec 8 2016!)
Code: 
root@prox01:~# openssl x509 -in /etc/pve/pve-root-ca.pem -noout -text
Certificate:
  Data:
  Version: 3 (0x2)
  Serial Number: 13706215231112316391 (0xbe364222517f85e7)
  Signature Algorithm: sha256WithRSAEncryption
  Issuer: CN=Proxmox Virtual Environment, OU=834ad1c6be0653aa2bca465961757fe6, O=PVE Cluster Manager CA
  Validity
  Not Before: Dec  8 09:50:45 2016 GMT
  Not After : Dec  6 09:50:45 2026 GMT
  Subject: CN=Proxmox Virtual Environment, OU=834ad1c6be0653aa2bca465961757fe6, O=PVE Cluster Manager CA

Best regards
Marco Menardi
Click to expand...

that can only happen if your clock is completely wrong on the first boot, in which case there is not much we can do.. we backdate the certificate by 1 day in order to compensate timezone confusion, but even that is already a workaround for semi-broken setups..
 
fabian said:
This will be fixed when the installer iso is rebuilt, as the problem is caused by a race condition on first boot of a freshly installed node. If you are affected by this and don't want to wait the X hours (depending on your timezone), you can do the following:
Code: 
rm /etc/pve/pve-root-ca.pem /etc/pve/priv/pve-root-ca.key
pvecm updatecerts -f

Which will recreate both the cluster CA and the node certificate and key.
Click to expand...


thank you had similar problem this
removing and regenerating worked.


Code: 
rm /etc/pve/pve-root-ca.pem /etc/pve/priv/pve-root-ca.key

pvecm updatecerts -f
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back