Kubernetes Client Certificate (RKE managed) - ssl

I'm currently deploying a K8S cluster through Rancher RKE using AWS EC2 virtual machines (with CentOS 7 and Docker 17.03.2-ce).
Unfortunately after depolying K8S dashboard, I'm not been able to access it from external, through API SERVER (https://API-server-ip:6443/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/).
Service are up and running without problems:
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default kubernetes ClusterIP 10.43.0.1 <none> 443/TCP 1h
ingress-nginx default-http-backend ClusterIP 10.43.76.101 <none> 80/TCP 1h
kube-system kube-dns ClusterIP 10.43.0.10 <none> 53/UDP,53/TCP 1h
kube-system kubernetes-dashboard ClusterIP 10.43.198.196 <none> 443/TCP 1h
I saw that PEM certificate have been already created within /etc/kubernetes/ssl of the API SERVER machine:
-rw-r--r--. 1 root root 1679 Apr 19 09:19 kube-apiserver-key.pem
-rw-r--r--. 1 root root 1302 Apr 19 09:19 kube-apiserver.pem
-rw-r--r--. 1 root root 1679 Apr 19 09:19 kube-ca-key.pem
-rw-r--r--. 1 root root 1017 Apr 19 09:19 kube-ca.pem
-rw-r--r--. 1 root root 493 Apr 19 09:19 kubecfg-kube-controller-manager.yaml
-rw-r--r--. 1 root root 437 Apr 19 09:19 kubecfg-kube-node.yaml
-rw-r--r--. 1 root root 441 Apr 19 09:19 kubecfg-kube-proxy.yaml
-rw-r--r--. 1 root root 457 Apr 19 09:19 kubecfg-kube-scheduler.yaml
-rw-r--r--. 1 root root 1675 Apr 19 09:19 kube-controller-manager-key.pem
-rw-r--r--. 1 root root 1062 Apr 19 09:19 kube-controller-manager.pem
-rw-r--r--. 1 root root 1679 Apr 19 09:19 kube-etcd-<...>-compute-amazonaws-com-key.pem
-rw-r--r--. 1 root root 1298 Apr 19 09:19 kube-etcd-<...>-us-east-2-compute-amazonaws-com.pem
-rw-r--r--. 1 root root 1679 Apr 19 09:19 kube-node-key.pem
-rw-r--r--. 1 root root 1070 Apr 19 09:19 kube-node.pem
-rw-r--r--. 1 root root 1675 Apr 19 09:19 kube-proxy-key.pem
-rw-r--r--. 1 root root 1046 Apr 19 09:19 kube-proxy.pem
-rw-r--r--. 1 root root 1675 Apr 19 09:19 kube-scheduler-key.pem
-rw-r--r--. 1 root root 1050 Apr 19 09:19 kube-scheduler.pem
I tried to use kube-apiserver-key.pem as key to generate a client certificate openssl req -new -key /etc/kubernetes/ssl/kube-apiserver-key.pem -out /tmp/user-cert.pem and eventually use it to access. Unfortunately the generated certificate is resulted to be in invalid format (I tried both to install on MacOS X and on SSL online validator.
Any help?

After several digging I managed to found a solution.
In the generate RKE kubeconfig generated file, both client-certificate-data and client-key-data are present as base64 encoded keys for kube-admin.
In order to use them in my client browser I had first to decode them for obtaining the respective certificate and key
echo '<KUBE_ADMIN_CLIENT_CERTIFICATE_DATA>' | base64 --decode > kube-admin-cert.pem
echo '<KUBE_ADMIN_CLIENT_KEY_DATA>' | base64 --decode > kube-admin-cert-key.pem
Once the certificates have been generated it's possibile to extract the correspondant .p12 certificate file
openssl pkcs12 -export -clcerts -inkey kube-admin-cert-key.pem -in kube-admin-cert.pem -out kube-admin-cert.p12
Eventually, once the p12 certificate has been installed in local client browser, it's possibile to authenticate successfully to the proxy api server.

Related

SSL Error:“unsupported certificate purpose” for HAProxy's client

I'm trying to set up client certificate authentication using HAProxy.
With OpenSSL, I have created a certificate chain as (CA cert --> Intermediate cert --> Server Cert) and After signing Intermediate with CA key and server cert with Intermediate key, I concat then in a sequence of (server-cert.pem + Intermediate-cert.pem + Root-cert.pem + Server-key.pem)
[root#ip-172-31-0-168 /]# cd /etc/ssl/CertChain
[root#ip-172-31-0-168 CertChain]# ls -la
total 52
drwxr-xr-x 2 root root 265 Jul 15 14:39 .
drwxr-xr-x 7 root root 86 Jul 15 13:29 ..
-rw-r--r-- 1 root root 2114 Jul 15 13:34 ca-cert.pem
-rw-r--r-- 1 root root 17 Jul 15 13:53 ca-cert.srl
-rw-r--r-- 1 root root 3268 Jul 15 13:34 ca-key.pem
-rw-r--r-- 1 root root 9374 Jul 15 14:39 haproxySSLFile.pem
-rw-r--r-- 1 root root 2000 Jul 15 13:53 Intermidate-cert.pem
-rw-r--r-- 1 root root 17 Jul 15 14:01 Intermidate-cert.srl
-rw-r--r-- 1 root root 3272 Jul 15 13:51 Intermidate-key.pem
-rw-r--r-- 1 root root 1781 Jul 15 13:51 Intermidate-req.pem
-rw-r--r-- 1 root root 1988 Jul 15 14:01 server-cert.pem
-rw-r--r-- 1 root root 3272 Jul 15 13:56 server-key.pem
-rw-r--r-- 1 root root 1769 Jul 15 13:56 server-req.pem
The highlighted file is the concatenated version of certificates, the location of the file I have placed within the HAProxy config file.
Once Haproxy is up and running I download CA-Cert.pem file from ssl cert directories and to test ssl encryption I choose postman(Client) where I upload that CA-Cert.pem file.
bind *:80
bind *:443 ssl crt /etc/ssl/CertChain/haproxySSLFile.pem
redirect scheme https if !{ ssl_fc }
mode http
default_backend apps
After Running this through postman(Client), I'm getting ( SSL Error: Unsupported certificate purpose)
Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : Yes
S/MIME signing CA : No
S/MIME encryption : Yes
S/MIME encryption CA : No
CRL signing : Yes
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No
Time Stamp signing : No
Time Stamp signing CA : No
Above is the list of certificate purposes, that is already defined. I'm not able to figure out what should be the specific purposes I need to specify as my goal is to encrypt/decrypt the incoming traffic through SSL for Haproxy.
Postman(Client) Error Summary
I've spent many hours attempting to figure out what the issue is, but I'm no closer.
So I would greatly appreciate any help!

Apache start fails

I am setting up a internal virtual host on Apache with a self signed certificate. I have my VirtualHost config and when I try to start Apache, I get an error stating the cert if either missing or empty. I have checked my persmissions and cert and everything looks proper so I'm not sure why i'm getting this error. What is wrong with my config?
VirtualHost config:
<VirtualHost *:443>
ServerName www1
ServerAlias www1
DocumentRoot /var/www/html
SSLEngine on
SSLCertificateFile /var/certs/www-cert.crt
SSLCertificateKeyFile /var/certs/www-cert.key
</VirtualHost>
The error from apache:
[root#www1 scripts]# systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Sat 2016-12-17 16:13:50 CST; 44s ago
Docs: man:httpd(8)
man:apachectl(8)
Process: 10109 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE)
Process: 10107 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
Main PID: 10107 (code=exited, status=1/FAILURE)
Dec 17 16:13:50 www1 systemd[1]: Starting The Apache HTTP Server...
Dec 17 16:13:50 www1 httpd[10107]: AH00526: Syntax error on line 6 of /etc/httpd/conf.d/default.conf:
Dec 17 16:13:50 www1 httpd[10107]: SSLCertificateFile: file '/var/certs/www-cert.crt' does not exist or is empty
Dec 17 16:13:50 www1 systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE
Dec 17 16:13:50 www1 kill[10109]: kill: cannot find process ""
Dec 17 16:13:50 www1 systemd[1]: httpd.service: control process exited, code=exited status=1
Dec 17 16:13:50 www1 systemd[1]: Failed to start The Apache HTTP Server.
Dec 17 16:13:50 www1 systemd[1]: Unit httpd.service entered failed state.
Dec 17 16:13:50 www1 systemd[1]: httpd.service failed.
The cert does exist:
[root#www1 scripts]# ls -la /var/certs
total 12
drwxr-xr-x. 2 root root 44 Dec 17 16:13 .
drwxr-xr-x. 22 root root 4096 Dec 17 14:57 ..
-rwxr-xr-x. 1 root root 1253 Dec 17 16:13 www-cert.crt
-rwxr-xr-x. 1 root root 1704 Dec 17 16:13 www-cert.key
The cert is valid:
[root#www1 scripts]# openssl x509 -text -noout -in /var/certs/www-cert.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 17817470849210419499 (0xf7445f561b10892b)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=CA, ST=Manitoba, OU=www1/emailAddress=root#localhost
Validity
Not Before: Dec 17 22:13:49 2016 GMT
Not After : Dec 11 22:13:49 2021 GMT
Subject: C=CA, ST=Manitoba, OU=www1/emailAddress=root#localhost
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b2:76:fa:a8:8a:0d:ee:97:2f:5c:f8:7d:2a:48:
e9:f8:ce:c6:df:62:5f:23:e4:be:ea:c0:9c:25:09:
31:30:df:90:fc:6b:1b:58:62:98:29:aa:13:39:93:
bc:4d:d2:b8:7a:9f:e8:09:c1:e6:dc:1d:57:67:67:
33:61:6e:eb:a8:52:a6:77:70:19:ed:2a:58:5a:79:
35:ba:af:18:c2:2f:be:06:6a:8b:33:12:e7:63:03:
63:12:36:ed:ae:8e:c5:13:b5:2a:be:25:ac:dc:8a:
a5:dc:bc:86:49:27:29:7f:cd:5e:e1:ec:d9:a5:9f:
34:63:cc:7b:34:fa:2e:27:da:7b:90:a2:27:46:9b:
0b:e1:0a:68:a2:ed:df:1a:b6:48:ef:4f:c9:23:a8:
cf:7e:4c:da:ff:1f:80:52:fb:15:10:39:03:b5:d2:
0d:64:4b:df:9c:0f:41:9a:a0:d8:a1:c7:25:aa:19:
ee:c6:01:81:8b:be:7a:d8:c6:8c:cd:8f:13:51:68:
6d:78:00:72:76:d7:19:9b:d1:66:73:43:4b:30:9b:
de:96:29:81:80:40:31:39:43:e1:c4:2c:4a:c0:19:
4e:9b:d1:f5:e7:2b:d5:36:e3:eb:ef:31:e5:32:b1:
53:5b:f7:a5:c1:17:94:e9:ab:79:e2:02:be:c0:6f:
98:b1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
2C:E5:06:10:BB:24:32:27:7A:7F:50:00:A8:A5:D6:FC:86:5C:58:1F
X509v3 Authority Key Identifier:
keyid:2C:E5:06:10:BB:24:32:27:7A:7F:50:00:A8:A5:D6:FC:86:5C:58:1F
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
05:69:cb:ee:4d:b5:3c:cb:c4:fb:2f:ac:26:b8:fd:db:bf:41:
69:d0:a2:5b:cd:cc:04:53:f5:32:fc:7d:c9:fb:54:9d:d4:bf:
41:02:09:0a:19:51:b1:69:bb:87:87:34:91:28:d4:1d:64:49:
3e:38:27:ad:74:91:4a:e2:dc:85:4f:56:92:ad:fe:f1:9d:17:
ca:e7:b2:2f:2f:89:62:fd:47:a0:0d:67:fb:6b:3b:8a:59:ae:
73:03:97:72:c7:4c:d7:23:a3:b7:1f:ed:8a:bf:03:8a:00:40:
1b:b4:02:d5:f6:73:45:4b:fd:1b:44:9d:9d:46:ca:c1:30:a0:
53:5d:a3:2b:da:09:84:e6:97:9c:66:e5:a2:92:12:99:c5:03:
7f:b7:f6:03:3d:d8:f3:ea:72:f4:ce:2b:73:dd:c6:72:e7:fb:
55:6e:b5:44:11:52:56:ce:3d:0b:d8:40:cb:7e:ed:89:06:c6:
ec:3a:0b:94:e7:54:ce:5e:d6:13:1f:3e:9f:35:47:9b:46:89:
97:80:62:14:f7:40:3e:f6:bc:d9:16:7e:c3:51:27:eb:ab:db:
80:d8:7e:ae:e5:a8:bb:09:28:73:ae:07:1f:78:79:b5:df:5f:
60:85:c3:1e:93:29:95:4e:92:c2:96:e8:ec:a8:46:51:05:a3:
eb:3d:96:f2

Amazon EC2 Linux Permissions with Magento 2

I have a Amazon AWS EC2 installation with vhosts file setup and StartCOM SSL Certificate. I have run through the installation setup passing the Magento Readyness checks completing the installation with success. I can access the Magento Administrative area without a problem, but the storefront loads with an Error 500.
I believe this to be a permissions problem, but require some assistance with troubleshooting and correcting the problem.
4.4.15-25.57.amzn1.x86_64
Apache/2.4.23 (Amazon)
PHP Version 7.0.9
Magento 2
/var/www/html/magento/
grep
apache /etc/group
ec2-user:x:500:apache
apache:x:48:
ls -l
total 1004
-rw-r--r-- 1 root apache 130922 Aug 21 09:59 access_log
drwxr-sr-x 4 root apache 4096 Jun 23 09:41 app
drwxr-sr-x 2 root apache 4096 Jun 23 09:41 bin
-rw-r--r-- 1 root apache 434798 Jun 23 09:41 CHANGELOG.md
-rw-r--r-- 1 root apache 1843 Jun 23 09:39 composer.json
-rw-r--r-- 1 root apache 340876 Jun 23 09:41 composer.lock
-rw-r--r-- 1 root apache 3381 Jun 23 09:41 CONTRIBUTING.md
-rw-r--r-- 1 root apache 631 Jun 23 09:41 COPYING.txt
drwxr-sr-x 5 root apache 4096 Jun 23 09:41 dev
-rw-r--r-- 1 root apache 408 Aug 21 09:32 error_log
-rw-r--r-- 1 root apache 2854 Jun 23 09:41 Gruntfile.js.sample
-rw-r--r-- 1 root apache 1358 Jun 23 09:41 index.php
-rw-r--r-- 1 root apache 315 Jun 23 09:41 ISSUE_TEMPLATE.md
drwxr-sr-x 4 root apache 4096 Jun 23 09:41 lib
-rw-r--r-- 1 root apache 10376 Jun 23 09:41 LICENSE_AFL.txt
-rw-r--r-- 1 root apache 10364 Jun 23 09:41 LICENSE.txt
-rw-r--r-- 1 root apache 5233 Jun 23 09:41 nginx.conf.sample
-rw-r--r-- 1 root apache 1427 Jun 23 09:41 package.json.sample
-rw-r--r-- 1 root apache 804 Jun 23 09:41 php.ini.sample
drwxr-sr-x 2 root apache 4096 Jun 23 09:41 phpserver
drwxr-sr-x 6 root apache 4096 Jun 23 09:41 pub
drwxr-sr-x 7 root apache 4096 Jun 23 09:41 setup
drwxr-sr-x 7 root apache 4096 Jun 23 09:39 update
drwxrwsr-x 11 root apache 4096 Aug 21 09:59 var
drwxrwsr-x 29 root apache 4096 Jun 23 09:41 vendor

Docker TLS Security on Remote Client

I'm writing a client that would use the Remote API from docker to consume the exposed REST services. I want to secure the communications between the client and server. I'm not fully familiar with certificate handling. I have programmatically included trust stores that contain the server's public certificate to my client. I understand that I have to follow the same approach. But I'm a bit perplexed after reading the documentation about it from Docker:
http://docs.docker.com/articles/https/
I understand that I have to generate two sets of keys, one for the server and the other for the client. Following the steps as written in the documentation of docker, I have the following generated:
MacBook-Pro:misc Joe$ ls -l
total 40
-rw-r--r-- 1 Joe staff 1743 Nov 19 23:06 ca-key.pem
-rw-r--r-- 1 Joe staff 1346 Nov 19 23:06 ca.pem
-rw-r--r-- 1 Joe staff 1743 Nov 19 23:10 key.pem
-rw-r--r-- 1 Joe staff 0 Nov 19 23:14 server-cert.pem
-rw-r--r-- 1 Joe staff 1751 Nov 19 23:07 server-key.pem
-rw-r--r-- 1 Joe staff 907 Nov 19 23:13 server.csr
What is the difference between ca-key.pem and ca.pem and likewise what is a server-cert.pem and server-key.pem? Which ones goes to the server and which ones are for the client?
But anyways, trying out the following gives me an error:
MacBook-Pro:misc Joe$ openssl x509 -req -days 365 -in server.csr -CA ca.pem -CAkey ca-key.pem -out server-cert.pem
Signature ok
subject=Dummy
Getting CA Private Key
Enter pass phrase for ca-key.pem:
ca.srl: No such file or directory
6502:error:02001002:system library:fopen:No such file or directory:/SourceCache/OpenSSL098/OpenSSL098-44/src/crypto/bio/bss_file.c:356:fopen('ca.srl','r')
6502:error:20074002:BIO routines:FILE_CTRL:system lib:/SourceCache/OpenSSL098/OpenSSL098-44/src/crypto/bio/bss_file.c:358:

Apache - Init: Can't open server private key file

I am enabling ssl on my apache running on localhost. I generated a self signed certificate and put it in a usual place:
[david#david web]$ ll /etc/ssl/certs/
...
-rwxrwxrwx. 1 david david 977 Mar 7 13:18 localhost.crt
-rwxrwxrwx. 1 david david 712 Mar 7 13:16 localhost.csr
-rwxrwxrwx. 1 david david 963 Mar 7 13:12 localhost.key
But when I restart Apache, the server fails and I receive the following in the error log:
[Fri Mar 07 13:29:17 2014] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0
[Fri Mar 07 13:29:17 2014] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Fri Mar 07 13:29:17 2014] [error] (13)Permission denied: Init: Can't open server private key file /etc/ssl/certs/localhost.key
The permissions look ok to me, what am I doing wrong?
This is because you probably uploaded the file(s) first to one of your home directories and then moved them somewhere in the /etc directory.
To correct the context of this file, execute the following command:
restorecon -RvF /etc/ssl/certs/
and restar Apache service httpd restart.
Hope it helps.
David,
I would suggest first to change the permissions and ownership on the key file
Change ownership:sudo chown root:root localhost.key
Change permissions:sudo chmod 600 localhost.key
To fix the problem, I needed to remove the passphrase from the key
Remove passphrase: openssl rsa -in localhost.key -out localhost_nopp.key
After that, just change the SSLCertificateKeyFile parameter to point to localhost_nopp.key and restart Apache.
I am guessing this produces a "clean" file that Apache is now happy to use. Since this appears to a development/test environment, the assumption is that removing the passphrase will not cause a major security issue.
Thanks,
John