Vault auth kubernetes backend and OpenShift - Part 2

[safe...@gmail.com]

Hello ... again. My apologies for the double posting, but it seems that something went wrong with my initial post. It says it got deleted, and I can't seem to post to it anymore. To recap;

First of, thanks for building a great open source product which has great community support.

I'm trying to get Vault to work with the Kubernetes Auth method in OpenShift. I'm following this guide published on the OpenShift blog which utilizes this code, but I'm running into a problem verifying that the authentication works in step B-11.

When I execute the "vault write -tls-skip-verify auth/kubernetes/login role=spring-native-example jwt=$default_account_token" command, I get certificate untrusted errors (Post https://kubernetes.openshift.ott1-eng.internal/apis/authentication.k8s.io/v1/tokenreviews: x509: certificate signed by unknown authority). I've tried several of the internally resolvable domains (kubernetes.default.svc etc), all resulting in the same errors. However, I have verified the certificate chain (by download the cert of the website via the container and loading up the CA from step B-4) with OpenSSL, even just by looking at the cert I can see the signer is the CA that is being loaded up by the plugin.

I've also tried redeploying our OpenShift cluster several times with different internal configurations, to no avail, and tried it on several production clusters. All return with the same error. But I won't wade too much into the OpenShift territory here.

So for the actual questions;
* The only possibly strange thing that I can see it that there are no Subject Alt Names on the cert. Is it possible that golang doesn't see a cert as valid if there aren't any SANs?
* Has anybody gotten this to work with either Kubernetes or OpenShift, or see any glaring errors in the linked blog post?

Jeff Mitchell suggested (thanks for the super quick reply! :)) that it might be because the CA chain wasn't on the container.

This was my suspicion as well, since it's not external but internal communication between vault and k8s master API. When I was investigating this issue, I started looking at the vault auth plugin source code and found out that it actually loads up the CA cert that has to be configured as a PEM in the vault config path. Regardless, I've also tried loading up the CA cert (including mounting the whole folder etc) into usr/local/share/ca-certificate and calling update-ca-certificate on startup, since the container supports this. Also, no joy :( Maybe you know of an alternative (and/or better) way of loading up the CA certificates into the vault container?

Maybe this is also why it seems as such a weird problem to me; I'd expect the internal communication between a container and "hosted" k8s APIs to "just work".

Again, apologies for the double posting and thank you for understanding.

All best, Joost

[Joost Test]

I've done another deployment of OpenShift and inspected the internally routed certificate (not the externally routed one), and I believe my suspicion not having IP Subject Alternative Names in the certificate results in GOLANG not trusting the certificate.was correct.

The Common Name is the IP of the machine, and the chain stops at the OpenShift signer (which is the CA cert loaded in the before mentioned tutorial), and which is being used by the vault authentication plugin.

However, when using it we get the following error

Error writing data to auth/kubernetes/login: Error making API request.

URL: PUT https://vault-aasvault.openshift.ott1-eng.internal/v1/auth/kubernetes/login
Code: 500. Errors:

* Post https://10.124.100.150/apis/authentication.k8s.io/v1/tokenreviews: x509: cannot validate certificate for 10.124.100.150 because it doesn't contain any IP SANs

Is there a way for me to tell Vault (or GOLANG) that this is OK? or is this a feature of GOLANG?

Thank you, Joost

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to a topic in the Google Groups "Vault" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vault-tool/h0c9nNEhmrM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vault-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/ca9eaec1-0439-4f69-a031-0046bd507eaa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeff Mitchell]

Hi,

What's the full dump of the certificate? Use: openssl x509 -in <cert.pem> -noout -text

Thanks,

Jeff

You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAOFC%2BHp2MAQJ91gN7RXPiY7VaO%2BCaEVc-q3r8t264bV5BtRg6Q%40mail.gmail.com.

[Joost Test]

Hey - This is the full cert, i used openssl s_client -connect since i'm not sure how to download the internal certificate within the controller.

CONNECTED(00000003)
depth=1 CN = openshift-signer@1516754909
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/CN=10.124.100.150
   i:/CN=openshift-signer@1516754909
 1 s:/CN=openshift-signer@1516754909
   i:/CN=openshift-signer@1516754909
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID/TCCAuWgAwIBAgIBAjANBgkqhkiG9w0BAQsFADAmMSQwIgYDVQQDDBtvcGVu
c2hpZnQtc2lnbmVyQDE1MTY3NTQ5MDkwHhcNMTgwMTI0MDA0ODMxWhcNMjAwMTI0
MDA0ODMyWjAZMRcwFQYDVQQDEw4xMC4xMjQuMTAwLjE1MDCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANzHtx6ef9h+JQpWyQ7F99/68tlcHu64drON3JFb
fYm2z2ZaE9lL1PXf+XBvHVnLq04NYZz7hF8N9Y5RlzZ25vOnZVSmOrNDojtlMLFg
RgUhhrpHv7myuu6H9YEbS9hAtSj+7gg3pHx0W44sOcmW1sbs/z2OzUnNrDL1ZZea
SsSLrbNEMUjcjqoEuW1+zypBfmGSd6T9TQiaeIe+crmrMu2SrclqKi2WRf+p8urT
tSBdikUgptLa2jsyn4ThAwzQsdIcK2QGP4DbsSjebjkxM/ArJ1peD6LZBrrgWmB+
wPgQ6mCWdT/pjjoLh5PEteGuZAytMkx/CuKbnJBCUMgiTuMCAwEAAaOCAUEwggE9
MA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDATAMBgNVHRMBAf8E
AjAAMIIBBgYDVR0RBIH+MIH7ggprdWJlcm5ldGVzghJrdWJlcm5ldGVzLmRlZmF1
bHSCFmt1YmVybmV0ZXMuZGVmYXVsdC5zdmOCJGt1YmVybmV0ZXMuZGVmYXVsdC5z
dmMuY2x1c3Rlci5sb2NhbIIJb3BlbnNoaWZ0ghFvcGVuc2hpZnQuZGVmYXVsdIIV
b3BlbnNoaWZ0LmRlZmF1bHQuc3ZjgiNvcGVuc2hpZnQuZGVmYXVsdC5zdmMuY2x1
c3Rlci5sb2NhbIIZb3NvbWQwMS5vdHQxLWVuZy5pbnRlcm5hbIIOMTAuMTI0LjEw
MC4xNTCCCjE3Mi4zMC4wLjGHBAp8ZJaHBKweAAEwDQYJKoZIhvcNAQELBQADggEB
AATo42EkrpHqT6zFS7t5Hv+PsjFia3DpwrEJwuB7pg8o26TJc9/IYPPw+sj9fX82
23ZZ+fXqimzc/HZ83Cq7gTj61HYcZ9WszNdtZ2ZWeb5Q7oHREpiNjyk9DvZgF2Qx
TYtOFtvG7HTT6WMBdi216hrDwRVt7jsryt0buTpGdFzc8AUGBlpAT8LZ6uzIrDO3
+ycou3Y7DoLOie7zKWFFoNQQkV1U686AhHW9Wz/2UKDl+QFsWvyPicUHUZjvz+nP
lII5K56b+Oy/I0MS0bMPMGzrIPonLVGhAJ7JSctomkGIOcbiNaOt3z3eAV/TNVnj
iqAWy822qS2oQh+NJoDr3Tk=
-----END CERTIFICATE-----
subject=/CN=10.124.100.150
issuer=/CN=openshift-signer@1516754909
---
Acceptable client certificate CA names
/CN=openshift-signer@1516754909
/CN=openshift-signer@1516755820
---
SSL handshake has read 2496 bytes and written 427 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: A83B13112BF3165B4841D0EB448F23BE58DCE5D181656ED1F3B377163F9E147B
    Session-ID-ctx:
    Master-Key: 10796D42ACF2D7228EF5E47C6E84A4AD6EFF46E7780D1A33E1CBB526B1870A89960ABB35C8A836D09D019CA5CE3112E8
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - f2 99 e4 3f 32 17 15 3d-03 b7 f6 aa b0 4a 6d cd   ...?2..=.....Jm.
    0010 - d3 79 c3 0e 7b 77 6d 7a-ec eb c9 97 f5 7f f9 ae   .y..{wmz........
    0020 - a4 8c 7e 9a 4b 1d 57 0a-83 18 6f 7d 36 05 fc 86   ..~.K.W...o}6...
    0030 - d9 89 43 ba 23 35 55 84-9c 30 39 e4 16 85 bb 80   ..C.#5U..09.....
    0040 - e5 ae 44 c5 b6 bb 00 64-8e 54 9a 4f b4 27 b0 eb   ..D....d.T.O.'..
    0050 - 38 44 1f e5 12 1e 60 13-99 c7 1a b3 02 9f 65 77   8D....`.......ew
    0060 - d4 13 05 77 c3 77 e6 23-3e d8 e5 bc f6 f7 75 4f   ...w.w.#>.....uO
    0070 - 88 26 12 fb 3a 46 8e 9a-                          .&..:F..

    Start Time: 1522857198
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---

Thanks!

 

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAORe8GGnDR5MWFV2tqf%2B-CXx1US%3Du5z4ybBGzchGe9KdS%2Ba50w%40mail.gmail.com.

[Jeff Mitchell]

Hi there,

You got this from openssl s_client against  https://10.124.100.150/apis/authentication.k8s.io/v1/tokenreviews ?

What version of Vault? The certificate is a bit wonky -- it has IP addresses in as DNS SANs in addition to IP SANs so I wonder if it's tripping up validation logic.

Generally speaking with a valid cert it there should be no issues w.r.t. Go.

Best,

Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAOFC%2BHo0MJtfemLY8cAFkMkDFhT1owXq-hK%2BrJ30suzW3dJkug%40mail.gmail.com.

[Joost Test]

Well seems that i stepped in it with that theory of mine :)

You got this from openssl s_client against  https://10.124.100.150/apis/authentication.k8s.io/v1/tokenreviews ?

Almost, i got this with "openssl s_client -connect kubernetes.default.svc:443" (again i have to apologize, i'm at a conference while i'm juggling a RedHat support ticket, my POs & Manager and this email thread). The IP one is actually a bit weirder, it gives me the following PEM

-----BEGIN CERTIFICATE-----
MIIDRTCCAi2gAwIBAgIBCTANBgkqhkiG9w0BAQsFADAmMSQwIgYDVQQDDBtvcGVu
c2hpZnQtc2lnbmVyQDE1MTY3NTQ5MDkwHhcNMTgwMTI0MDEyODMyWhcNMjAwMTI0
MDEyODMzWjAoMSYwJAYDVQQDEx0qLm9wZW5zaGlmdC5vdHQxLWVuZy5pbnRlcm5h
bDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANCj3STsIl8b95Nb2egC
IhM7vy6HeIPkcYJ2ScfAUQlCFK3b7+LVWK9IfJFTNExB+Lvt/vIqi2QolZVz7NMl
1nF2DfQU4+cmOtHoUH4RUT1zh2xFUuqObb8/QncGOE/x5LFJTpQGDvOS5uYj27PI
J/YJaQTkE3gLi7vLBPTKC3OPjPqF010+EZ01vgIF3o1R72ybflyOmykLuH7sS1dg
9/nth7z3eCbOjqcVTcK00IWhq7NW50su/jpZ8cLMXuAo7Ahz1UVFe5WKMDURiugF
9Th4bZz9yXyVj+Bfg3NjATm1D7cXHYnHGT1xK+3zGVL1niGYsvCxcZiVem3JB4VI
QhUCAwEAAaN8MHowDgYDVR0PAQH/BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMB
MAwGA1UdEwEB/wQCMAAwRQYDVR0RBD4wPIIdKi5vcGVuc2hpZnQub3R0MS1lbmcu
aW50ZXJuYWyCG29wZW5zaGlmdC5vdHQxLWVuZy5pbnRlcm5hbDANBgkqhkiG9w0B
AQsFAAOCAQEAEsaYuZye4/6aVkPW20z3f0+lfGUnBvdoOenldmtkpYg3lkW34qx7
6AauijVDVU9RIyu9DFtzkCbUIhfyQYBQmWVaw0RlZpFCPXl+P6UkYrJVtjEfV5da
2sAiCX8XH5IwYT38VyPHTxxgppCXSCsn7qh03yVDkjUyPdYS+PgYmZ+xEOhVEhIt
q3f1FMhF8zVcWAA3Xbd9pDJ40EdpyAtEfWJzk6091FzCnC33Vr1kLrRe/SCSKR8Q
9UBVPzmzFeh5VLyO+gBxAk3y2MlEP0r82KG6Fvun/KK+ny0HZ5lUiKf4/h4hyW7K
G36UhdH09lZIzYPBM26+f/RpoQAaQjYzSg==
-----END CERTIFICATE-----

which results in Common Name: *.openshift.ott1-eng.internal: and SANs *.openshift.ott1-eng.internal, openshift.ott1-eng.internal

What version of Vault? The certificate is a bit wonky -- it has IP addresses in as DNS SANs in addition to IP SANs so I wonder if it's tripping up validation logic.

Generally speaking with a valid cert it there should be no issues w.r.t. Go.

We're using Origin V3.7.

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAORe8GFTY%2BTs_MdKy1J%2Bc43LV0%2BW-AeHGQa7AOoJhW5meq3Bjg%40mail.gmail.com.

[Joost Test]

Just to add: <anything>.openshift.ott1-eng.internal also doesn’t work. I could share my ansible inventory file if that helps?

Sent from my iPhone

[Joost Test]

@jeff - Is there anyway you can run a test on your end for this, maybe a unit test?

[Jeff Mitchell]

Hi Joost,

I'm not sure what you are asking for us to do. As you noted, the certificate you are actually using doesn't have IP SANs, but you are trying to connect to it via IP. It is correct behavior for this connection to be considered invalid.

Best,

Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAOFC%2BHqJXy0V-3FA4RX5pp%2B5DC8MBdz4oWaJDiM-1DiPhzhWUw%40mail.gmail.com.

[Jeff Mitchell]

For reference, here is your certificate:

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number: 9 (0x9)

    Signature Algorithm: sha256WithRSAEncryption

        Issuer: CN=openshift-signer@1516754909

        Validity

            Not Before: Jan 24 01:28:32 2018 GMT

            Not After : Jan 24 01:28:33 2020 GMT

        Subject: CN=*.openshift.ott1-eng.internal

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                Public-Key: (2048 bit)

                Modulus:

                    00:d0:a3:dd:24:ec:22:5f:1b:f7:93:5b:d9:e8:02:

                    22:13:3b:bf:2e:87:78:83:e4:71:82:76:49:c7:c0:

                    51:09:42:14:ad:db:ef:e2:d5:58:af:48:7c:91:53:

                    34:4c:41:f8:bb:ed:fe:f2:2a:8b:64:28:95:95:73:

                    ec:d3:25:d6:71:76:0d:f4:14:e3:e7:26:3a:d1:e8:

                    50:7e:11:51:3d:73:87:6c:45:52:ea:8e:6d:bf:3f:

                    42:77:06:38:4f:f1:e4:b1:49:4e:94:06:0e:f3:92:

                    e6:e6:23:db:b3:c8:27:f6:09:69:04:e4:13:78:0b:

                    8b:bb:cb:04:f4:ca:0b:73:8f:8c:fa:85:d3:5d:3e:

                    11:9d:35:be:02:05:de:8d:51:ef:6c:9b:7e:5c:8e:

                    9b:29:0b:b8:7e:ec:4b:57:60:f7:f9:ed:87:bc:f7:

                    78:26:ce:8e:a7:15:4d:c2:b4:d0:85:a1:ab:b3:56:

                    e7:4b:2e:fe:3a:59:f1:c2:cc:5e:e0:28:ec:08:73:

                    d5:45:45:7b:95:8a:30:35:11:8a:e8:05:f5:38:78:

                    6d:9c:fd:c9:7c:95:8f:e0:5f:83:73:63:01:39:b5:

                    0f:b7:17:1d:89:c7:19:3d:71:2b:ed:f3:19:52:f5:

                    9e:21:98:b2:f0:b1:71:98:95:7a:6d:c9:07:85:48:

                    42:15

                Exponent: 65537 (0x10001)

        X509v3 extensions:

            X509v3 Key Usage: critical

                Digital Signature, Key Encipherment

            X509v3 Extended Key Usage: 

                TLS Web Server Authentication

            X509v3 Basic Constraints: critical

                CA:FALSE

            X509v3 Subject Alternative Name: 

                DNS:*.openshift.ott1-eng.internal, DNS:openshift.ott1-eng.internal

    Signature Algorithm: sha256WithRSAEncryption

         12:c6:98:b9:9c:9e:e3:fe:9a:56:43:d6:db:4c:f7:7f:4f:a5:

         7c:65:27:06:f7:68:39:e9:e5:76:6b:64:a5:88:37:96:45:b7:

         e2:ac:7b:e8:06:ae:8a:35:43:55:4f:51:23:2b:bd:0c:5b:73:

         90:26:d4:22:17:f2:41:80:50:99:65:5a:c3:44:65:66:91:42:

         3d:79:7e:3f:a5:24:62:b2:55:b6:31:1f:57:97:5a:da:c0:22:

         09:7f:17:1f:92:30:61:3d:fc:57:23:c7:4f:1c:60:a6:90:97:

         48:2b:27:ee:a8:74:df:25:43:92:35:32:3d:d6:12:f8:f8:18:

         99:9f:b1:10:e8:55:12:12:2d:ab:77:f5:14:c8:45:f3:35:5c:

         58:00:37:5d:b7:7d:a4:32:78:d0:47:69:c8:0b:44:7d:62:73:

         93:ad:3d:d4:5c:c2:9c:2d:f7:56:bd:64:2e:b4:5e:fd:20:92:

         29:1f:10:f5:40:55:3f:39:b3:15:e8:79:54:bc:8e:fa:00:71:

         02:4d:f2:d8:c9:44:3f:4a:fc:d8:a1:ba:16:fb:a7:fc:a2:be:

         9f:2d:07:67:99:54:88:a7:f8:fe:1e:21:c9:6e:ca:1b:7e:94:

         85:d1:f4:f6:56:48:cd:83:c1:33:6e:be:7f:f4:69:a1:00:1a:

         42:36:33:4a

There are no IP SANs, so it does not validate when accessing via IP. You can either access via hostname, or get a certificate with appropriate IP SANs.

Best,

Jeff

[Joost Test]

> As you noted, the certificate you are actually using doesn't have IP SANs, but you are trying to connect to it via IP. It is correct behavior for this connection to be considered invalid

As I've noted in previous emails I've tried various combinations; kubernetes.default.svc(.cluster.local), the host name of the master host (osomd01.ott1-eng.internal), the master url of the host (openshift.ott1-eng.internal or kubernetes.ott1-eng.internal), the IP of the host, and other strange combinations I've found in the various tutorials and source on the web. All seemed to result in the same type of errors in within Vault. I've not only tried to connect via IP, but also via the valid host(s) in the cert

> There are no IP SANs, so it does not validate when accessing via IP. You can either access via hostname, or get a certificate with appropriate IP SANs.

Could you clarify what you mean? From your earlier message I understood that when you read the certs there were entries for the host IP in both IP & DNS SANs, and you seemed to indicate that the certificate might be wonky because of this and that your were wondering " if it's tripping up validation logic ".

I missed this because I didn't resolve the entire PEM the first go around, and just went on the output of the command. After your comment I decoded the full PEM and saw what you said in your message.

So I took this PEM, and dumped it into SSLShopper for quicky decoding

-----BEGIN CERTIFICATE-----
MIID/TCCAuWgAwIBAgIBAjANBgkqhkiG9w0BAQsFADAmMSQwIgYDVQQDDBtvcGVu
c2hpZnQtc2lnbmVyQDE1MTY3NTQ5MDkwHhcNMTgwMTI0MDA0ODMxWhcNMjAwMTI0
MDA0ODMyWjAZMRcwFQYDVQQDEw4xMC4xMjQuMTAwLjE1MDCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANzHtx6ef9h+JQpWyQ7F99/68tlcHu64drON3JFb
fYm2z2ZaE9lL1PXf+XBvHVnLq04NYZz7hF8N9Y5RlzZ25vOnZVSmOrNDojtlMLFg
RgUhhrpHv7myuu6H9YEbS9hAtSj+7gg3pHx0W44sOcmW1sbs/z2OzUnNrDL1ZZea
SsSLrbNEMUjcjqoEuW1+zypBfmGSd6T9TQiaeIe+crmrMu2SrclqKi2WRf+p8urT
tSBdikUgptLa2jsyn4ThAwzQsdIcK2QGP4DbsSjebjkxM/ArJ1peD6LZBrrgWmB+
wPgQ6mCWdT/pjjoLh5PEteGuZAytMkx/CuKbnJBCUMgiTuMCAwEAAaOCAUEwggE9
MA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDATAMBgNVHRMBAf8E
AjAAMIIBBgYDVR0RBIH+MIH7ggprdWJlcm5ldGVzghJrdWJlcm5ldGVzLmRlZmF1
bHSCFmt1YmVybmV0ZXMuZGVmYXVsdC5zdmOCJGt1YmVybmV0ZXMuZGVmYXVsdC5z
dmMuY2x1c3Rlci5sb2NhbIIJb3BlbnNoaWZ0ghFvcGVuc2hpZnQuZGVmYXVsdIIV
b3BlbnNoaWZ0LmRlZmF1bHQuc3ZjgiNvcGVuc2hpZnQuZGVmYXVsdC5zdmMuY2x1
c3Rlci5sb2NhbIIZb3NvbWQwMS5vdHQxLWVuZy5pbnRlcm5hbIIOMTAuMTI0LjEw
MC4xNTCCCjE3Mi4zMC4wLjGHBAp8ZJaHBKweAAEwDQYJKoZIhvcNAQELBQADggEB
AATo42EkrpHqT6zFS7t5Hv+PsjFia3DpwrEJwuB7pg8o26TJc9/IYPPw+sj9fX82
23ZZ+fXqimzc/HZ83Cq7gTj61HYcZ9WszNdtZ2ZWeb5Q7oHREpiNjyk9DvZgF2Qx
TYtOFtvG7HTT6WMBdi216hrDwRVt7jsryt0buTpGdFzc8AUGBlpAT8LZ6uzIrDO3
+ycou3Y7DoLOie7zKWFFoNQQkV1U686AhHW9Wz/2UKDl+QFsWvyPicUHUZjvz+nP
lII5K56b+Oy/I0MS0bMPMGzrIPonLVGhAJ7JSctomkGIOcbiNaOt3z3eAV/TNVnj
iqAWy822qS2oQh+NJoDr3Tk=
-----END CERTIFICATE-----

Which resulted in the following Common Name (i.e. Subject) and Subject Alternative Names as your noted in previous emails.

Common Name: 10.124.100.150
Subject Alternative Names: kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, openshift, openshift.default, openshift.default.svc, openshift.default.svc.cluster.local, osomd01.ott1-eng.internal, 10.124.100.150, 172.30.0.1, IP Address:10.124.100.150, IP Address:172.30.0.1

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAORe8GGBF_tvt4CRm_YEhbsiCrtB%2Bg8yvO%3DhaSc793Aq-X3FsA%40mail.gmail.com.

[Jeff Mitchell]

Hi there,

I've got to be honest, I'm not really tracking what certificate came from where. Here's my understanding:

* The original certificate you showed me came from <somewhere> but is *not* the certificate you received when performing the openssl s_client call using the IP address as the host name. This cert does have IP SANs.

* When I asked you to fetch the cert using the IP address as the host name, you pasted a different certificate. This certificate does not have IP SANs.

Assuming I'm correct, to me the problem seems pretty straightforward -- when you fetch a certificate using the IP address the one that comes back does not have IP SANs so can't be verified, which is correct behavior. Why this is happening is a separate question, and one for the OpenShift support resources.

Best,

Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAOFC%2BHqFKjy1z4Uy2oRz1LggM7NN80YyFp08_Tu81Qeu4nzpjQ%40mail.gmail.com.