"At this moment, I can't see any safe solution - because opening AD controllers to the restricted VLAN doesn't seem suitable to me, however I don't see at the moment any other way how to (automatically, using certificate renewal process) deliver certificate for an on--going process of granting access."
Coincidentally, I had run into this very issue while building out my test network for an upcoming NAC review. Like the writer of this email, I too had computers that I needed to join to Active Directory and receive a computer certificate, but I had already enabled 802.1X on the switches. Without a way to authenticate to the switch and subsequently get an IP address, I was stuck.
I had three options, recable the devices into a switch that had 802.1X disabled. That would have worked, but I hate moving cables around because it just leads to tangles. I could have disabled 802.1X on the switches, but I just configured them for 802.1X. I hate going backwards almost as much as I hate moving cables around. My final option, and the one I used, was to login to the network using a username and password, join the computer to the domain and request a computer certificate. Problem solved.
This translates into a production environment easily. Microsoft's Internet Authentication Service (IAS), aka a RADIUS server, supports multiple profiles, so I created one profile that used PEAP for certificate authentication and another policy for username and password authentication. In the latter policy, I restricted logins to a specific user group that I called Provisioning. When I created a new host, I could login using an account that belonged to the Provisioning group and I could complete the host installation. For newly provisioned hosts, I would recommend simply connecting hosts to a non-802.1X switch that is separated from the rest of the network but can still access the Active Directory. Once the hosts are provisioned, they can be placed anywhere.