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!
Related
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.
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 have been attemping to code sign a dll using a code signing certiticate I have purchased from Comodo. The intention for the signing is to be verifiable via the kernel signing policy. However, in the the EventLog explaining that there are CodeIntegrity errors relating to per-page image hashes not being able to be found.
Below is a summary I what I am doing, if you could please provide advice on where I have gone wrong, or where to look next that would be greatly appreciated.
I have signed a previously signed dll for the sake of testing using the following commands, the result is the same if I used a newly built dll.
"C:\WinDDK\7600.16385.1\bin\amd64\SignTool.exe" sign /v /ph /ac "addtrustexternalcaroot_kmod.crt" /f css-certificate.pfx /p <password> /t http://timestamp.verisign.com/scripts/timstamp.dll VBoxVRDP.dll
The output is as follows
The following certificate was selected:
Issued to: S4 Technology
Issued by: COMODO RSA Code Signing CA
Expires: Wed Nov 11 15:59:59 2015
SHA1 hash: 0161DC2D8757B886E626B25B1770C72B789BAF02
Cross certificate chain (using machine store):
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 05:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: AddTrust External CA Root
Issued by: Microsoft Code Verification Root
Expires: Tue Aug 15 12:36:30 2023
SHA1 hash: A75AC657AA7A4CDFE5F9DE393E69EFCAB659D250
Issued to: COMODO RSA Certification Authority
Issued by: AddTrust External CA Root
Expires: Sat May 30 02:48:38 2020
SHA1 hash: F5AD0BCC1AD56CD150725B1C866C30AD92EF21B0
Issued to: COMODO RSA Code Signing CA
Issued by: COMODO RSA Certification Authority
Expires: Mon May 08 15:59:59 2028
SHA1 hash: B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47
Issued to: S4 Technology
Issued by: COMODO RSA Code Signing CA
Expires: Wed Nov 11 15:59:59 2015
SHA1 hash: 0161DC2D8757B886E626B25B1770C72B789BAF02
Done Adding Additional Store
Successfully signed and timestamped: VBoxVRDP.dll
Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0
I now validate the signing using the following command
"C:\WinDDK\7600.16385.1\bin\amd64\SignTool.exe" verify /v /ph /kp VBoxVRDP.dll
The output is as follows
Verifying: VBoxVRDP.dll
Hash of file (sha1): 41909BD87A05CF3E61BBEF7B9DD4C4A8B6E4B2A1
Signing Certificate Chain:
Issued to: AddTrust External CA Root
Issued by: AddTrust External CA Root
Expires: Sat May 30 02:48:38 2020
SHA1 hash: 02FAF3E291435468607857694DF5E45B68851868
Issued to: COMODO RSA Certification Authority
Issued by: AddTrust External CA Root
Expires: Sat May 30 02:48:38 2020
SHA1 hash: F5AD0BCC1AD56CD150725B1C866C30AD92EF21B0
Issued to: COMODO RSA Code Signing CA
Issued by: COMODO RSA Certification Authority
Expires: Mon May 08 15:59:59 2028
SHA1 hash: B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47
Issued to: S4 Technology
Issued by: COMODO RSA Code Signing CA
Expires: Wed Nov 11 15:59:59 2015
SHA1 hash: 0161DC2D8757B886E626B25B1770C72B789BAF02
The signature is timestamped: Mon Dec 15 10:05:37 2014
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Thu Dec 31 15:59:59 2020
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires: Wed Dec 30 15:59:59 2020
SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires: Tue Dec 29 15:59:59 2020
SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4
Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 05:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: AddTrust External CA Root
Issued by: Microsoft Code Verification Root
Expires: Tue Aug 15 12:36:30 2023
SHA1 hash: A75AC657AA7A4CDFE5F9DE393E69EFCAB659D250
Issued to: COMODO RSA Certification Authority
Issued by: AddTrust External CA Root
Expires: Sat May 30 02:48:38 2020
SHA1 hash: F5AD0BCC1AD56CD150725B1C866C30AD92EF21B0
Issued to: COMODO RSA Code Signing CA
Issued by: COMODO RSA Certification Authority
Expires: Mon May 08 15:59:59 2028
SHA1 hash: B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47
Issued to: S4 Technology
Issued by: COMODO RSA Code Signing CA
Expires: Wed Nov 11 15:59:59 2015
SHA1 hash: 0161DC2D8757B886E626B25B1770C72B789BAF02
Embedded page hashes:
0x00000000 7B54C3ABC3FC7DA85CB40074D653DFB36DF8E0F9
<...>
0x00071a00 0000000000000000000000000000000000000000
Successfully verified: VBoxVRDP.dll
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
So it all looks good, however, I have noted when looking at the properties of dll via Explorer, but I end up with a CodeIntegrity errors in the EventLog.
Code Integrity is unable to verify the image integrity of the file <...>\VBoxVRDP.dll because the set of per-page image hashes could not be found on the system.
When I look at the Verbose logs of CodeIntegrity I see the following Verbose events
Code Integrity started validating page hashes of <...>\VBoxVRDP.dll file.
Code Integrity completed validating page hashes. Status 0xc0000428.
From what I can tell 0xc0000428 is Windows cannot verify the digital signature of this file, which seems to imply I am missing something somewhere, but I for the life of me cannot figure out exactly what it is I need to do.
Windows support for SHA2 on Win 7 seems to be problematic at present. https://technet.microsoft.com/en-us/library/security/2949927.aspx
There is a fix but note "Revision V2.0 (October 17, 2014): Removed Download Center links for Microsoft security update 2949927. Microsoft recommends that customers experiencing issues uninstall this update. Microsoft is investigating behavior associated with this update, and will update the advisory when more information becomes available."
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