vSphere 6.0’s certtool forgets template.cfg to create CSR

I was trying to generate a CSR. We decided to put the PSC as a subordinate CA in our environment. There are already a few good posts on the net which explain how to do this, so I followed the steps and started editing the


this should be the template which will be used by Certool to create a CSR.

Let’s start certtool, like mentioned in the most internet posts, Choose 2 … Choose 1 create new cert, put it on a CSR checker fails. Strange let’s see…..huh company VMware, Location US. Strange this wasn’t in my template file, looks like it didn’t us it.

After a little search I found


Hah so this is a known issue, tought I did something wrong, so I followed the steps in the document, created/copied the CFG I already created.


certool --initcsr --privkey=priv.key --pubkey=pub.key --csrfile=csr.csr --config=certool_acme.cfg


Well this worked perfect, while letting our PKI sign the certificate we couldn’t properly import the certificate. When troubleshooting this we noticed that our PKI administrator used some wrong templates which made the SubCA we requested an end entity CSR.


After some mailing we suddenly received a properly signed certificate which was a SubCA signed one.

After following the original documentation guides we could easily install the certificate.

KDC has no support for encryption type (14)

This morning was like every morning, everything up and running and had good cup of coffee. All VMware components worked fine.

After that I went to a meeting, had some talk with colleagues and came back to my workplace. Mmm a colleague tells me that he can’t login to vCenter anymore, we have 2 seperate vCenters in 2 diffent datacenters. Somehow he couldn’t login in both vCenters. Strange, as they have very few components shared.

First thing I tought of was authentication, logged in with admin@vsphere.local user in webclient and checked SSO settings. When testing the connection I got an error.

The settings in SSO for LDAP are:

  • Reuse session (this was our setting and didn’t work anymore)
  • Password (this works with my own user account so AD should be ok?)
  • Anonymous (Prohibited error)

So somehow, when I use the option password the authentication to AD is fine, but with reuse session I get an error.

Let’s check the SSO logging :

C:\Program Files\VMware\Infrastructure\SSOServer\logs\imsTrace.log

The errors I found where like:

Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: KDC has no support for encryption type (14))]
Caused by: GSSException: No valid credentials provided (Mechanism level: KDC has no support for encryption type (14))

So let’s ask the security team if happened something in the time I had a meeting.

“Uh yes we upgraded the functional domain level from Windows2003 to Windows2008”

*To be sure I rebooted the vCenters in the meanwhile

Ah so we might have a trigger which caused this issue. When searching the internet I find a similar error messages:



I adviced the security team to restart the Domain Controllers or restart the service. Because the impact of restarting the service is unknown we decided to restart the domain controllers later that evening.

As a workaround I used the SSO “Password” option with a service account to let people login and don’t disturb the backup process.

The day after domain controllers where rebooted, I changed the authentication type back to “Reuse session” and tested the connection….BINGO! Worked again.

The problem was probably like described in the posts, there isn’t much public information on this I could find. Our security team even verified with Microsoft for impact and stuff, but never had this mentioned.

Well took me a few minutes of my day :S