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
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!
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
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
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:
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