x509: certificate is valid for photon-platform.vmware.com only.

[tactical-drone]

I do not understand.

For some reason I just cannot follow the photon installation instructions. I am just too dumb. I am trying to connect the CLI so that I can configure some kubernetes flavors, but it won't let me.

I get the following problem:

noob@photon-dev:~$ photon target set https://10.0.0.42:443
Certificate (with below fingerprint) presented by API server (10.0.0.42:443) isn't trusted.
MD5 = E19BE412E4D1C2DD10EB14FE19E358F1
SHA1  = 9D5C13ED9F0E38C5EEA1DC6FFE56A69E83D9430F
Do you trust this certificate for future communication? (yes/no): yes
Saved your preference for future communicaition with API server 10.0.0.42:443
2017/04/10 14:48:02 Error: Get https://10.0.0.42:443/auth: x509: cannot validate certificate for 10.0.0.42 because it doesn't contain any IP SANs

noob@photon-dev:~$ photon target set https://lb-1.ctlab.com:443
Certificate (with below fingerprint) presented by API server (lb-1.ctlab.com:443) isn't trusted.
MD5 = E19BE412E4D1C2DD10EB14FE19E358F1
SHA1  = 9D5C13ED9F0E38C5EEA1DC6FFE56A69E83D9430F
Do you trust this certificate for future communication? (yes/no): yes
Saved your preference for future communicaition with API server lb-1.ctlab.com:443
2017/04/10 14:48:06 Error: Get https://lb-1.ctlab.com:443/auth: x509: certificate is valid for photon-platform.vmware.com, not lb-1.ctlab.com

It does not make sense. The code says that photon-platform.vmware.com was baked in. But how can that be? It makes no sense!? What am I missing here? It just makes no sense at all? Has anybody been able to install this thing at all?

Shouldn't the load balancer's IP or DNS name be used instead of photon-platform.vmware.com? This stuff is driving me crazy. Either or the installation instructions are simply wrong.

[tactical-drone]

Hacking /etc/hosts with a 10.0.0.42 photon-platform.vmware.com fixes the authentication for now but this is simply unacceptable.

root@photon-dev:/home/griftw/src/keys# vim /etc/hosts
noob@photon-dev:~/src/keys$ photon target set https://photon-platform.vmware.com:443
Certificate (with below fingerprint) presented by API server (photon-platform.vmware.com:443) isn't trusted.
MD5 = E19BE412E4D1C2DD10EB14FE19E358F1
SHA1  = 9D5C13ED9F0E38C5EEA1DC6FFE56A69E83D9430F
Do you trust this certificate for future communication? (yes/no): yes
Saved your preference for future communicaition with API server photon-platform.vmware.com:443
Certificate (with below fingerprint) presented by Authentication server (10.0.0.40:443) isn't trusted.
MD5 = F08B270113BB904FEE9128F11AD10257
SHA1  = F456E1A0598A5D94D07B144C507FD56163482F52
Do you trust this certificate for future communication? (yes/no): yes
Saved your preference for future communicaition with Authentication server 10.0.0.40:443
Certificate (with below fingerprint) presented by Authentication server (10.0.0.40:443) isn't trusted.
MD5 = F08B270113BB904FEE9128F11AD10257
SHA1  = F456E1A0598A5D94D07B144C507FD56163482F52
Do you trust this certificate for future communication? (yes/no): yes
Saved your preference for future communicaition with Authentication server 10.0.0.40:443
API target set to 'https://photon-platform.vmware.com:443'
noob@photon-dev:~/src/keys$ 

[AlainRoy]

Hi @pompomJuice:

I'd like to follow up on a few issues:

1. I think your biggest blocking problem would have been avoided if the installer verified the version of ESXi you had installed. I'll work to get this into the next release. Internally, I've filed this as bug #1848108.

2. We are working to open source the installer and upstream our changes to Thrift. While I don't have a timeline for these yet, I expect they will happen.

3. If you do photon target set -c https://photon-platform.vmware.com:443 (note the -c) it will skip the validation. I agree that that's not good enough. It looks to me like our certificates do not contain the appropriate subject alternate names--I'll investigate a solution for this. I want to do a little more investigation before I file a bug on this, but I'll be doing that today.

Thanks for your feedback. -alain

[tactical-drone]

@AlainRoy

When the kubernetes install failed because the flavors were not there I switched to this documentation instead of your documentation to achieve kubernetes support for default flavor loading using photon-cli. I subsequently found out what they are doing and what you guys are doing are not totally aligned. Your flavors described in #96 are the real deal it seems.

So what I said was not true. I did not read your instructions. I apologize. I will calm down.

The thing that frustrates me is that I should be getting my documentation from the code, not the internet. But the code is not available. Not all of it. Think how much value you would get if instead of creating a huge troll you get pull requests instead. I cannot understand why all the code is not loaded. Just licence the thing up. You are vmware you have money to pay lawyers to sort out revenue protection. Do what Oracle does. Oracle cant wait for you to use an illegal copy of their software. Fire sales through lawyers.

[tactical-drone]

@AlainRoy I want to be clear about:

I think your biggest blocking problem would have been avoided if the installer verified the version of ESXi you had installed. I'll work to get this into the next release. Internally, I've filed this as bug #1848108.

The issue was not that the version number was wrong, it was right! The problem was that the update did not take. This is a serious issue. This means that depending on whether the issue sits with Dell or ESXi upgrade path, everyone will dell servers (or everybody) that upgraded to the correct version will have the same issue I had.

That maybe explains why that other guy said his one server worked but not the other. There was another guy who said that he though he did apply the update, but when he went through the KB manually it started working. That is what led me to one of my last avenues I haven't checked, reinstalling my ESXi wit same issue I had.

That maybe explains why that other guy said his one server worked but not the other. There was another guy who said that he though he did apply the update, but when he went through the KB manually it started working. That is what led me to one of my last avenues I haven't checked, reinstalling my ESXi with the correct image from the getgo.

Therefor, I believe running the upgrade from dell ESXi boot cd does not work.