I'm using pyOpenSSL to create a X509 certifcate. I need to import this certificate into a Java JKS keystore to make it available to my Java application. This is working fine as long as I don't add a subjectAltName extension to the certificate. If the certificate has an alternative subject set, import into the JKS keystore fails:
root#51561a8a1e01:~# /opt/oracle/java/jdk64-1.8.0_92/bin/keytool -keystore keystore -storepass changeit -noprompt -importcert -alias example -file certificate.crt -v
keytool error: java.lang.Exception: Input not an X.509 certificate
java.lang.Exception: Input not an X.509 certificate
at sun.security.tools.keytool.Main.doCommands(Main.java:1009)655)
at sun.security.tools.keytool.Main.main(Main.java:336)
root#51561a8a1e01:~#
If I print this certificate using OpenSSL on the command line, I get this output:
root#51561a8a1e01:~# openssl x509 -in certificate.crt -text -noout
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 0 (0x0)
Signature Algorithm: sha256WithRSAEncryption
Issuer: OU=example.com, CN=my-server.example.com, O=example.com
Validity
Not Before: Aug 26 12:03:03 2016 GMT
Not After : Aug 25 12:03:03 2021 GMT
Subject: OU=example.com, CN=my-server.example.com, O=example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:cc:a7:53:5a:38:...:11:2f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:localhost
Signature Algorithm: sha256WithRSAEncryption
ab:51:12:fb:a6:a6:...:0d:4b
That is the certificate is obviously valid. And according to oracle's documentation the Java 8 keytool should support the SubjectAlternativeName extension.
When I tried to generate everything with keytool itself - which seems to work - I noticed that the certificate generated by keytool has a second extension X509v3 Subject Key Identifier:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1510484556 (0x5a082a4c)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=example.com, OU=example.com, CN=my-server.example.com
Validity
Not Before: Aug 26 12:52:43 2016 GMT
Not After : Nov 24 12:52:43 2016 GMT
Subject: O=example.com, OU=example.com, CN=my-server.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:99:b6:b1:11:a6:...:7b:39
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:localhost
X509v3 Subject Key Identifier:
66:75:AD:7A:A5:19:AB:43:DE:55:E4:A7:4F:C2:3D:53:55:49:CE:48
Signature Algorithm: sha256WithRSAEncryption
50:7c:fe:c8:5d:1b:...:da:27
Do I need to add this extension to my certificate using pyOpenSSL as well. But what would be the correct value?!
Well, just after writing down everything for this question I noticed that there is a second difference between the certificate generated with pyOpenSSL and the keytool one. The keytool certificate states Version: 3 (0x2) while the other one says Version: 1 (0x0).
I'm not too much into the X509 specs but as the extensions are all prefixed with X509v3 I'd guess that extension support is not available for version 1 certificates.
And after adapting my python code to set the version to 3 (actually 2 as version is 0 based), import into keytool works as expected:
_req = OpenSSL.crypto.X509Req()
_req.set_version(2)
...
Related
I have a keystore with an old invalid server certificate that needs to be replaced and I have a file with a certificate chain containing 4 certificates: root, intermediates and server certificate. When I try
to import it only the first certificate gets imported. I have tried to import only the server certificate but the application will not pick it up.
How can I import the certificate chain? what alias should I use?
What is the relation with the already existing private key in the keystore?
How can I validate that its working?
command used:
keytool -importcert -file filename.cer -keystore server.jks -alias "url"
keystore entry:
api.tokbox.com-4, Nov 23, 2017, trustedCertEntry, Certificate
fingerprint (SHA1):
27:96:BA:E6:3F:18:01:E2:77:26:1B:A0:D7:77:70:02:8F:20:EE:E4
rs-service-dev_cloudservices_XXX_com, Nov 2, 2018, PrivateKeyEntry,
Certificate fingerprint (SHA1):
96:B0:CC:7C:D0:F7:4F:88:11:53:43:63:23:76:EE:AA:58:BD:D5:C6
api.tokbox.com-3, Nov 23, 2017, trustedCertEntry, Certificate
fingerprint (SHA1):
34:0B:28:80:F4:46:FC:C0:4E:59:ED:33:F5:2B:3D:08:D6:24:29:64
api.tokbox.com-2, Nov 23, 2017, trustedCertEntry, Certificate
fingerprint (SHA1):
27:AC:93:69:FA:F2:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8
api.tokbox.com-1, Nov 23, 2017, trustedCertEntry, Certificate
fingerprint (SHA1):
9A:0D:F8:41:26:93:28:F5:02:9F:41:BB:7C:E1:C2:84:21:B4:A9:15
Certificate file:
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
I wanted to have the public key of a server. The team managing the server said to me that i can extract the certificates using openssl e.g. with command
openssl s_client -connect hostAddress.org:443 -showcerts
and this certificate will have the public key.
Using the above command, i get 3 certificates. The full output of the command is:
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Assured ID Root CA
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
0 s:/C=CZ/L=Praha/O=CESNET/CN=hostAddress
i:/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3
-----BEGIN CERTIFICATE-----
SOME TEXT
-----END CERTIFICATE-----
1 s:/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA
-----BEGIN CERTIFICATE-----
SOME TEXT
-----END CERTIFICATE-----
2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA
-----BEGIN CERTIFICATE-----
SOME TEXT
-----END CERTIFICATE-------
Server certificate
subject=/C=CZ/L=Praha/O=CESNET/CN=hostAddress
issuer=/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5097 bytes and written 489 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-SHA384
Session-ID: 5B9A6ACCEFE2608E33AEE1FAF8F3136A7C41D081416F885613A0C48A4D9556CD
Session-ID-ctx:
Master-Key: 83D7239981A232F1AB175F2F4980B1D6B7B1D4109878022A8FE8B3D2CD95F14D33AB2112E5F27CD1D508CE3D5EE34854
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1536846540
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
From these 3 certificates, how do i know which one has the public key for the host?
The certificate labelled 0 is the server certificate. The certificate labelled 1 is the certificate for the Certificate Authority (CA) which issued the server certificate, (and so on, ) up to the last one (the somewhat standard "2"), which is the root certificate where "oh, I trust this" was established.
So, you're looking for the first one.
I'm trying to install kubernetes with kubelet 1.4.5 on CoreOS beta (1192.2.0).
I'm using a slightly modified version of the controller and worker install scripts from https://github.com/coreos/coreos-kubernetes/tree/master/multi-node/generic
so in general I created the licenses on Gentoo Linux using the following bash script:
#!/bin/bash
export MASTER_HOST=coreos-2.tux-in.com
export K8S_SERVICE_IP=10.3.0.1
export WORKER_IP=10.79.218.3
export WORKER_FQDN=coreos-3.tux-in.com
openssl genrsa -out ca-key.pem 2048
openssl req -x509 -new -nodes -key ca-key.pem -days 10000 -out ca.pem -subj "/CN=kube-ca"
openssl genrsa -out apiserver-key.pem 2048
openssl req -new -key apiserver-key.pem -out apiserver.csr -subj "/CN=kube-apiserver" -config openssl.cnf
openssl x509 -req -in apiserver.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out apiserver.pem -days 365 -extensions v3_req -extfile openssl.cnf
openssl genrsa -out ${WORKER_FQDN}-worker-key.pem 2048
openssl req -new -key ${WORKER_FQDN}-worker-key.pem -out ${WORKER_FQDN}-worker.csr -subj "/CN=${WORKER_FQDN}" -config worker-openssl.cnf
openssl x509 -req -in ${WORKER_FQDN}-worker.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out ${WORKER_FQDN}-worker.pem -days 365 -extensions v3_req -extfile worker-openssl.cnf
openssl genrsa -out admin-key.pem 2048
openssl req -new -key admin-key.pem -out admin.csr -subj "/CN=kube-admin"
openssl x509 -req -in admin.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out admin.pem -days 365
echo done
and this is openssl.cnf
[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = #alt_names
[alt_names]
DNS.1 = coreos-2.tux-in.com
DNS.2 = coreos-3.tux-in.com
IP.1 = 10.3.0.1
IP.2 = 10.79.218.2
IP.3 = 10.79.218.3
and this is my worker-openssl.cnf
[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = #alt_names
[alt_names]
IP.1 = 10.79.218.3
DNS.1 = coreos-3.tux-in.com
My controller machine is coreos-2.tux-in.com which resolves to the lan ip 10.79.218.2
my worker machine is coreos-3.tux-in.com which resolves to lan ip 10.79.218.3
it created the licenses just fine. but when I use them and install the controller script on the main machine, i see that when I run journalctl -xef -u kubelet and I noticed the following messages:
Nov 08 21:24:06 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:06.805868 2018 event.go:208] Unable to write event: 'x509: certificate signed by unknown authority' (may retry after sleeping)
Nov 08 21:24:06 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:06.950827 2018 reflector.go:203] pkg/kubelet/kubelet.go:384: Failed to list *api.Service: Get https://coreos-2.tux-in.com:443/api/v1/services?resourceVersion=0: x509: certificate signed by unknown authority
Nov 08 21:24:07 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:07.461042 2018 reflector.go:203] pkg/kubelet/config/apiserver.go:43: Failed to list *api.Pod: Get https://coreos-2.tux-in.com:443/api/v1/pods?fieldSelector=spec.nodeName%3D10.79.218.2&resourceVersion=0: x509: certificate signed by unknown authority
Nov 08 21:24:07 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:07.461340 2018 reflector.go:203] pkg/kubelet/kubelet.go:403: Failed to list *api.Node: Get https://coreos-2.tux-in.com:443/api/v1/nodes?fieldSelector=metadata.name%3D10.79.218.2&resourceVersion=0: x509: certificate signed by unknown authority
Nov 08 21:24:08 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:08.024366 2018 reflector.go:203] pkg/kubelet/kubelet.go:384: Failed to list *api.Service: Get https://coreos-2.tux-in.com:443/api/v1/services?resourceVersion=0: x509: certificate signed by unknown authority
Nov 08 21:24:08 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:08.171170 2018 eviction_manager.go:162] eviction manager: unexpected err: failed GetNode: node '10.79.218.2' not found
Nov 08 21:24:08 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:08.543619 2018 reflector.go:203] pkg/kubelet/kubelet.go:403: Failed to list *api.Node: Get https://coreos-2.tux-in.com:443/api/v1/nodes?fieldSelector=metadata.name%3D10.79.218.2&resourceVersion=0: x509: certificate signed by unknown authority
Nov 08 21:24:08 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:08.543926 2018 reflector.go:203] pkg/kubelet/config/apiserver.go:43: Failed to list *api.Pod: Get https://coreos-2.tux-in.com:443/api/v1/pods?fieldSelector=spec.nodeName%3D10.79.218.2&resourceVersion=0: x509: certificate signed by unknown authority
The kubelet documentation says that the --tls-cert-file flag needs the CA be concatenated after the certificate. In you case it is the apiserver.pem:
--tls-cert-file File containing x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory passed to --cert-dir.
If I read you certificate generation correctly, the apiserver.pem doesn't contain the root ca.
0. if your issue is :
: Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "x509: invalid signature: parent certificate cannot sign this kind of certificate"
1. look at your ca.crt
openssl x509 -noout -text -in ca.crt, you will find below info :
X509v3 Basic Constraints:
CA:FLASE
X509v3 Basic Constraints means :
"Basic Constraints" identifies if the subject of certificates is a CA who is allowed to issue child certificates. For a certificate that can be used to sign certificates, the info is in some sense duplicated: X509v3 Basic Constraints: CA: TRUE --- Can sign certificates.
you should modify it to CA:TRUE through vi openssl.conf
[ v3_ca ]
basicConstraints = CA:true
Regenerate your crts.
I'm using kubelet with rkt on CoreOS 1192.2.0.
This is the unit i use to start kubelet on the worker:
[Unit]
Description=Kubelet via Hyperkube ACI
Requires=k8s-assets.target
After=k8s-assets.target
[Service]
EnvironmentFile=/etc/proxy.env
Environment="RKT_OPTS=--volume=resolv,kind=host,source=/etc/resolv.conf --mount volume=resolv,target=/etc/resolv.conf --volume var-log,kind=host,source=/var/log --mount volume=var-log,target=/var/log"
Environment=KUBELET_VERSION=v1.4.0_coreos.0
ExecStartPre=/usr/bin/mkdir -p /etc/kubernetes/manifests
ExecStart=/usr/lib/coreos/kubelet-wrapper \
--api-servers=https://10.203.69.108 \
--register-node=true \
--allow-privileged=true \
--config=/etc/kubernetes/manifests \
--hostname-override=node2.my.domain \
--cluster_dns=10.3.0.10 \
--cluster_domain=cluster.local \
--kubeconfig=/etc/kubernetes/worker-kubeconfig.yaml \
--tls-cert-file=/etc/kubernetes/ssl/worker.pem \
--tls-private-key-file=/etc/kubernetes/ssl/worker-key.pem
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
What is important is
--api-servers that must point to the IP address of the master
--tls-cert-file that must point to the worker certificate public key
--tls-private-key-file that must point to the worker certificate private key
--kubeconfig that must point to a valid kubeconfig file
Here my kubeconfig file (it contain the path to the CA that have signed the certificates):
apiVersion: v1
kind: Config
clusters:
- name: local
cluster:
certificate-authority: /etc/kubernetes/ssl/ca.pem
users:
- name: kubelet
user:
client-certificate: /etc/kubernetes/ssl/worker.pem
client-key: /etc/kubernetes/ssl/worker-key.pem
contexts:
- context:
cluster: local
user: kubelet
name: kubelet-context
current-context: kubelet-context
Your OpenSSL certificates are "self-signed":
openssl genrsa -out ca-key.pem 2048
openssl req -x509 -new -nodes -key ca-key.pem -days 10000 -out ca.pem -subj "/CN=kube-ca"
That is to say, you are signing them instead of a trusted certificate authority. It should be completely fine and safe, as long as you keep the private keys safe.
If you want it to be signed by a certificate authority, you will need to generate a CSR (certificate signing request).
https://www.digitalocean.com/community/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs
in general the solution was to create another etcd2 port that attaches to loopback device of each machine and works on http instead of https. more information at calico-policy-controller requests etcd2 certificates of a different coreos server
I am new to windows drivers and the signing procedure that's required for production use.
I recently purchased a GoDaddy Driver Signing Certificate and they ensured me that it should be working for kernel mode drivers, however I can not seem to be able to make it work.
After compiling I sign the .cat file with signtool with this command:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool" sign /n "COMPANY_NAME" /t http://timestamp.verisign.com/scripts/timstamp.dll mydriver.cat
This finishes successfully and I verify the certificate with this command:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool" verify /kp /v mydriver.cat
The output of the above commands states that is successful. You can see the output below
Verifying: mydriver.cat
Signature Index: 0 (Primary Signature)
Hash of file (sha1): AB24DC3601D29CE37CC2611EDEB7C8E3FBD89D04
Signing Certificate Chain:
Issued to: Go Daddy Class 2 Certification Authority
Issued by: Go Daddy Class 2 Certification Authority
Expires: Thu Jun 29 19:06:20 2034
SHA1 hash: 2796BAE63F1801E277261BA0D77770028F20EEE4
Issued to: Go Daddy Secure Certification Authority
Issued by: Go Daddy Class 2 Certification Authority
Expires: Mon Nov 16 03:54:37 2026
SHA1 hash: 7C4656C3061F7F4C0D67B319A855F60EBC11FC44
Issued to: <COMPANY_NAME>
Issued by: Go Daddy Secure Certification Authority
Expires: Sat Jul 23 19:23:39 2016
SHA1 hash: B53404B368EED5A734D332C10702B5D5B5C8E5DE
The signature is timestamped: Sat Jul 25 11:37:02 2015
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Fri Jan 01 01:59:59 2021
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires: Thu Dec 31 01:59:59 2020
SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires: Wed Dec 30 01: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 15:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: Go Daddy Class 2 Certification Authority
Issued by: Microsoft Code Verification Root
Expires: Sun Aug 27 19:48:23 2023
SHA1 hash: D9612472EF0F2787E2B2D9E063A06B32FA5E333D
Issued to: Go Daddy Secure Certification Authority
Issued by: Go Daddy Class 2 Certification Authority
Expires: Mon Nov 16 03:54:37 2026
SHA1 hash: 7C4656C3061F7F4C0D67B319A855F60EBC11FC44
Issued to: <COMPANY_NAME>
Issued by: Go Daddy Secure Certification Authority
Expires: Sat Jul 23 19:23:39 2016
SHA1 hash: B53404B368EED5A734D332C10702B5D5B5C8E5DE
Successfully verified: mydriver.cat
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
The cross certificate part seems to be good. I noticed from a similar output I found online (which was signed from GlobalSign) that the Signing Certificate Chain also led all the way up to Microsoft Code Verification Root. Could this be the problem? And if so how would I go about fixing that?
Installing the .inf goes smoothly, but when I start the driver using
net start mydriver
I get the error:
System error 577 has occurred.
Windows cannot verify the digital signature for this file. A recent hardware or
software change might have installed a file that is signed incorrectly or damage
d, or that might be malicious software from an unknown source.
If I reboot with driver signing enforcement off the above command works fine and the driver works. I have also checked that files in C:\Windows\System32\DriverStore\FileRepository is also signed the same way after installing them.
Does anyone know why the signing does not work, or how I could go about fixing this issue?
Thank you in advance!
I managed to solve my problem, thanks to Ashigore for directing me the right direction.
The problem was related to my intermediate certificates. It seemed like my certificate store was messed up where some intermediate certificates did not have a valid path up to a root CA.
I deleted every certificate that was related to my certificate and started from scratch.
Now the path is correct as:
Microsoft Code Verification Root
Go Daddy Class 2 Certification Authority
Go Daddy Secure Certification Authority
My companies certificate
The Microsoft Code Verification Root was not found at all, and I read somewhere that this certificate is hidden in the kernel somewhere and can not be found be certmgr. However it is possible to install it from microsoft if need be from here http://www.microsoft.com/pki/certs/MicrosoftCodeVerifRoot.crt
I don't think it is necessary tho...
I signed the driver files using these commands:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool" sign /v /ac "Go Daddy Class 2 Certification Authority.cer" /n "MY COMPANY" /t http://timestamp.verisign.com/scripts/timestamp.dll mydriver.cat
"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool" sign /v /ac "Go Daddy Class 2 Certification Authority.cer" /n "MY COMPANY" /t http://timestamp.verisign.com/scripts/timestamp.dll mydriver.sys
New output from verification command:
Verifying: mydriver.sys
File is signed in catalog: kaac.cat
Hash of file (sha1): 0AFAFD987F9C4B1D0BCBBD7851C0EA89AEF413C0
Signing Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 15:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: Go Daddy Class 2 Certification Authority
Issued by: Microsoft Code Verification Root
Expires: Sun Aug 27 19:48:23 2023
SHA1 hash: D9612472EF0F2787E2B2D9E063A06B32FA5E333D
Issued to: Go Daddy Secure Certification Authority
Issued by: Go Daddy Class 2 Certification Authority
Expires: Mon Nov 16 03:54:37 2026
SHA1 hash: 7C4656C3061F7F4C0D67B319A855F60EBC11FC44
Issued to: MY COMPANY
Issued by: Go Daddy Secure Certification Authority
Expires: Sat Jul 23 19:23:39 2016
SHA1 hash: B53404B368EED5A734D332C10702B5D5B5C8E5DE
The signature is timestamped: Sat Jul 25 14:14:29 2015
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Fri Jan 01 01:59:59 2021
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires: Thu Dec 31 01:59:59 2020
SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires: Wed Dec 30 01: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 15:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: Go Daddy Class 2 Certification Authority
Issued by: Microsoft Code Verification Root
Expires: Sun Aug 27 19:48:23 2023
SHA1 hash: D9612472EF0F2787E2B2D9E063A06B32FA5E333D
Issued to: Go Daddy Secure Certification Authority
Issued by: Go Daddy Class 2 Certification Authority
Expires: Mon Nov 16 03:54:37 2026
SHA1 hash: 7C4656C3061F7F4C0D67B319A855F60EBC11FC44
Issued to: MY COMPANY
Issued by: Go Daddy Secure Certification Authority
Expires: Sat Jul 23 19:23:39 2016
SHA1 hash: B53404B368EED5A734D332C10702B5D5B5C8E5DE
Successfully verified: mydriver.sys
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
I have followed all the steps for implementing pushnotification using the raywenderlich tutorial but I'm getting an error while running this command:
openssl s_client -connect gateway.sandbox.push.apple.com:2195 -cert XYZCert.pem -key XYZKey.pem
CONNECTED(00000003)
depth=1 /C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated
by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
**verify error:num=20:unable to get local issuer certificate
verify return:0**
---
Certificate chain
0 s:/C=US/ST=California/L=Cupertino/O=Apple Inc./OU=iTMS Engineering/CN=gateway.sandbox.push.apple.com
i:/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
1 s:/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
i:/O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048)
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFGzCCBAOgAwIBAgIETBz90jANBgkqhkiG9w0BAQUFADCBsTELMAkGA1UEBhMC
VVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0
Lm5ldC9ycGEgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMW
KGMpIDIwMDkgRW50cnVzdCwgSW5jLjEuMCwGA1UEAxMlRW50cnVzdCBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eSAtIEwxQzAeFw0xMjA1MjUyMzM3NDZaFw0xNDA1MzEw
NTA4NDhaMIGPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAG
A1UEBxMJQ3VwZXJ0aW5vMRMwEQYDVQQKEwpBcHBsZSBJbmMuMRkwFwYDVQQLExBp
VE1TIEVuZ2luZWVyaW5nMScwJQYDVQQDEx5nYXRld2F5LnNhbmRib3gucHVzaC5h
cHBsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC/r1z4BRFu
DIU9/vOboVmd7OwaPPLRtcZiZLWxSyG/6KeRPpaeaC6DScvSDRoJuIeTDBup0bg4
08K0Gzh+lfKRlJOC2sma5Wgvk7oP4sty83My3YCZQv4QvgDhx+seONNs6XiA8Cl4
ingDymWGlzb0sTdfBIE/nWiEOtXQZcg6GKePOWXKSYgWyi/08538UihKK4JZIOL2
eIeBwjEwlaXFFpMlStc36uS/8oy+KMjwvuu3HazNMidvbGK2Z68rBnqnOAaDBtuT
K7rwAa5+i8GYY+sJA0DywMViZxgG/xWWyr4DvhtpHfUjyQgg1ixM8q651LNgdRVf
4sB0PfANitq7AgMBAAGjggFZMIIBVTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYI
KwYBBQUHAwEGCCsGAQUFBwMCMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwu
ZW50cnVzdC5uZXQvbGV2ZWwxYy5jcmwwZQYIKwYBBQUHAQEEWTBXMCMGCCsGAQUF
BzABhhdodHRwOi8vb2NzcC5lbnRydXN0Lm5ldDAwBggrBgEFBQcwAoYkaHR0cDov
L2FpYS5lbnRydXN0Lm5ldC9sMWMtY2hhaW4uY2VyMEAGA1UdIAQ5MDcwNQYJKoZI
hvZ9B0sCMCgwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cuZW50cnVzdC5uZXQvcnBh
MB8GA1UdIwQYMBaAFB7xq4kG+EkPATN37hR67hl8kyhNMB0GA1UdDgQWBBSgNiNR
qtTShi8PuJ7UNUEbeE71STAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUAA4IBAQAS
EDkUyBHVdRJnCLHY8w9ec92NWqBYqKiSGP0uVCvgpsJIWDBkCGIw1Olks6mQuS9+
R7VRJJFg7EhtufmoRIvjgntKpTe49sB/lrmiZVQGnhjd6YdyYm9+OBUWRvwketLM
v0S+nxZD0qLLJ9foVUB8zP8LtutqFJ5IZw1xb9eSNzhpKkQ9ylj8MCd4tpXZxICL
Gt327poTXwmjQ+31fz7HCQCowMHccP8kiKM5SeYC9q+nkmdaozHVvw4e1RsP+EWO
vPtcH1x1BCkTJajmrO7JuRPLuBEnZGSPUVFRKWP9jy0a28VnJek+oA7rRMRD8irU
fMGbLqkGn8YogdPqe5T1
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Cupertino/O=Apple Inc./OU=iTMS Engineering/CN=gateway.sandbox.push.apple.com
issuer=/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
---
**No client certificate CA names sent**
---
SSL handshake has read 2731 bytes and written 2160 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID:
Session-ID-ctx:
Master-Key: CE7F8C43CF32CC6E2F9C81E8898E89EAEC8B4E1110B7AA50C0FDABB3ED628A0623C7905B956E6F28A0E85A4AECA9986B
Key-Arg : None
Start Time: 1339390594
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
**read:errno=54**
I am able to get the device token and while using php code to send notification it is showing:
Connected to APNS
Message successfully delivered
But I'm still not receiving notifications on iphone4s.
With every profile I'm getting the same device token.
So totally stuck with notification. How to resolve this?
does APNS return error-response packet to you?
if your token is invalid or the notification malformed, APNS will return the error-response.