OpenSC Program Crash with c0000005 on Windows - pkcs#11

All, I am trying to access opensc dll(latest version) on windows 7 64 bit. I am trying to access a ePass2003 token. The opensc-tool is able to detect the token and can get name and other information. So the token is found by OpenSC. Then I am loading the opensc dll from another program and call standard PKCS#11 functions. C_GetSlotList is returning slot 0 ID as -1 and slot 1 ID as 1. The C_GetFunctionList is returning me pointers to functions. The problem is when I call C_GetMechanismList I am getting a crash with c0000005 error.
I also have accessed the token through the ePass dll provided with the token, it works perfectly.
I am unable to track this problem as it is looking like through the opensc dll, opensc is unable to interface with the card but then opensc-tool also should have the same problem but it does not.
If someone can help it would be great.
TRACE : pkcs11-tool
Trace #1:
C:\Program Files\OpenSC Project\OpenSC\tools>pkcs11-tool.exe --module opensc-pkcs11.dll -I
Cryptoki version 2.20
Manufacturer OpenSC (www.opensc-project.org)
Library Smart card PKCS#11 API (ver 0.0)
Using slot 1 with a present token (0x1)
Trace #2:
C:\Program Files\OpenSC Project\OpenSC\tools>pkcs11-tool.exe --module opensc-pkcs11.dll -L
Available slots:
Slot 0 (0xffffffff): Virtual hotplug slot
(empty)
Slot 1 (0x1): FS USB Token 0
token state: uninitialized
Trace #3:
C:\Program Files\OpenSC Project\OpenSC\tools>pkcs11-tool.exe --module opensc-pkcs11.dll -T
Available slots:
No slots.
Trace #4:
C:\Program Files\OpenSC Project\OpenSC\tools>pkcs11-tool.exe --module opensc-pkcs11.dll -M
Using slot 1 with a present token (0x1)
Same result crash with c0000005

OpenSC PKCS#11 library sees your token as "uninitialized". If I remember correctly ePass token initialized with Feitian middleware cannot be used with OpenSC, and vice versa. So if you want to use ePass with opensc-pkcs11.dll then you will need to use pkcs15-init.exe application shipped with OpenSC to initialize your token.
Documentation references:
OpenSC wiki mentions requirement for reinitialization on ePass3000 page but not on ePass2003 page. European distributor gooze.eu also states that reinitialization is required:
The reason is that the ePass2003 is pre-initialized to be recognised
under Windows7 by Feitian priprietary software. To be usable, the
ePass2003 need to be initialized by OpenSC.
Practical examples:
I have initialized my ePass2003 token with Feitian middleware and tested with proprietary eps2003csp11.dll library - it was working fine:
C:\Program Files (x86)\OpenSC Project\OpenSC\tools>pkcs11-tool.exe --module eps2003csp11.dll -M
Using slot 0 with a present token (0x1)
Supported mechanisms:
RSA-PKCS-KEY-PAIR-GEN, keySize={1024,2048}, hw, encrypt, decrypt, sign, verify, generate_key_pair
RSA-PKCS, keySize={512,2048}, hw, encrypt, decrypt, sign, sign_recover, verify, verify_recover, wrap, unwrap
RSA-X-509, keySize={512,2048}, encrypt, decrypt, sign, sign_recover, verify, verify_recover, wrap, unwrap
MD2-RSA-PKCS, keySize={512,2048}, sign, verify
MD5-RSA-PKCS, keySize={512,2048}, sign, verify
SHA1-RSA-PKCS, keySize={512,2048}, hw, sign, verify
DH-PKCS-KEY-PAIR-GEN, keySize={128,2048}, generate_key_pair
DH-PKCS-DERIVE, keySize={128,2048}, derive
SHA256-RSA-PKCS, keySize={512,2048}, hw, sign, verify
SHA384-RSA-PKCS, keySize={512,2048}, sign, verify
SHA512-RSA-PKCS, keySize={1024,2048}, sign, verify
mechtype-70, keySize={512,2048}, sign, verify
RC2-KEY-GEN, keySize={8,1024}, generate
RC2-ECB, keySize={8,1024}, encrypt, decrypt
RC2-CBC, keySize={8,1024}, encrypt, decrypt
RC2-CBC-PAD, keySize={8,1024}, encrypt, decrypt
RC4-KEY-GEN, keySize={8,2048}, generate
RC4, keySize={8,2048}, encrypt, decrypt
DES-KEY-GEN, keySize={56,56}, generate
DES-ECB, keySize={64,64}, hw, encrypt, decrypt
DES-CBC, keySize={64,64}, hw, encrypt, decrypt
DES-CBC-PAD, keySize={64,64}, encrypt, decrypt
DES3-KEY-GEN, keySize={112,112}, generate
DES3-ECB, keySize={128,192}, hw, encrypt, decrypt
DES3-CBC, keySize={128,192}, hw, encrypt, decrypt
DES3-CBC-PAD, keySize={128,192}, encrypt, decrypt
MD2, digest
MD5, digest
SHA-1, keySize={512,512}, hw, digest, sign, verify
SHA-1-HMAC, keySize={8,2048}, sign, verify
SHA256, keySize={512,512}, hw, digest, sign, verify
mechtype-597, digest
SHA384, digest
SHA512, digest
GENERIC-SECRET-KEY-GEN, keySize={8,2048}, generate
AES-KEY-GEN, keySize={128,256}, generate
AES-ECB, keySize={128,256}, hw, encrypt, decrypt
AES-CBC, keySize={128,256}, hw, encrypt, decrypt
AES-CBC-PAD, keySize={128,256}, encrypt, decrypt
Then I have tested with opensc-pkcs11.dll and got the same crash you are describing:
C:\Program Files (x86)\OpenSC Project\OpenSC\tools>pkcs11-tool.exe --module opensc-pkcs11.dll -M
Using slot 1 with a present token (0x1)
So I have erased the card..
C:\Program Files (x86)\OpenSC Project\OpenSC\tools>pkcs15-init.exe --erase-card
Using reader with a card: FS USB Token 0
..initialized with OpenSC pkcs15-init application..
C:\Program Files (x86)\OpenSC Project\OpenSC\tools>pkcs15-init.exe --create-pkcs15 --profile pkcs15+onepin --use-default-transport-key --pin 0000 --puk 111111 --label "ePass2003"
Using reader with a card: FS USB Token 0
2014-07-29 22:35:08.208 cannot lock memory, sensitive data may be paged to disk
2014-07-29 22:35:08.442 cannot lock memory, sensitive data may be paged to disk
2014-07-29 22:35:08.882 cannot lock memory, sensitive data may be paged to disk
2014-07-29 22:35:10.059 cannot lock memory, sensitive data may be paged to disk
2014-07-29 22:35:10.497 cannot lock memory, sensitive data may be paged to disk
..and then opensc-pkcs11.dll started working:
C:\Program Files (x86)\OpenSC Project\OpenSC\tools>pkcs11-tool.exe --module opensc-pkcs11.dll -M
Using slot 1 with a present token (0x1)
Supported mechanisms:
SHA-1, digest
SHA256, digest
SHA384, digest
SHA512, digest
MD5, digest
RIPEMD160, digest
GOSTR3411, digest
RSA-X-509, keySize={512,2048}, hw, decrypt, sign, verify
RSA-PKCS, keySize={512,2048}, hw, decrypt, sign, verify
SHA1-RSA-PKCS, keySize={512,2048}, sign, verify
SHA256-RSA-PKCS, keySize={512,2048}, sign, verify
MD5-RSA-PKCS, keySize={512,2048}, sign, verify
RIPEMD160-RSA-PKCS, keySize={512,2048}, sign, verify
RSA-PKCS-KEY-PAIR-GEN, keySize={512,2048}, generate_key_pair
However eps2003csp11.dll distributed by Feitian stopped working as expected:
C:\Program Files (x86)\OpenSC Project\OpenSC\tools>pkcs11-tool.exe --module eps2003csp11.dll -M
No slot with a token was found.

Related

What exactly is meant by "Signature Algorithm" on a certificate? Which signature algorithm is being used to sign my certificate?

I am new to learning about certificates & their use in cybersecurity. I was experimenting around with my browser's certificate issued by GTS which is google trust services.
Now, I am confused about what the signature algorithm field means. I tried to google search this and found that the signature algorithm refers to the algorithm used to sign the certificate. If that is the case, I don't understand why I see 3 different signature algorithm fields in my cert. Also, 2 of them have a key size associated with them while the first field does now.
The first signature algorithm is under the category of "Issuer" so I thought maybe this is the algorithm being used to sign the cert. The second & third fields, shown in the second image, are under the category of public key. So what are they being used to sign?
Also, I don't see any key associated with the first signature algorithm, so I am a bit confused with this. Any help is much appreciated! Thank you!
Meta: this is not a programming issue, but I can't fit this in a comment. I am not voting to close because it is inappropriate to do so after answering, but if I am notified the question is closed I will delete (or I authorize a mod to do so) to ensure Q can be deleted or roombad.
I don't know what program you are using to get that decode, or if you have modified it beyond the black-outs, but it appears to be seriously misleading. Here is a better decode from OpenSSL, which follows the ASN.1 structure, with <<# marks added by me:
(redacted)>openssl s_client -connect www.google.com:443 <NUL 2>NUL | openssl x509 -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
45:48:e6:58:30:39:c0:ad:0a:00:00:00:00:ff:65:fa
Signature Algorithm: sha256WithRSAEncryption <<#1A
Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
Validity
Not Before: Sep 13 04:06:57 2021 GMT
Not After : Nov 20 04:06:56 2021 GMT
Subject: CN = www.google.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d7:27:92:c3:bb:e0:95:f4:20:46:a4:1a:5f:96:
78:a7:58:9d:cb:7c:2a:9c:7c:cb:2d:be:30:e9:c1:
71:80:11:da:c3:57:c4:c1:74:5c:a6:26:64:c3:49:
53:7c:44:19:f2:b3:c4:b3:5f:fc:90:30:b3:d4:31:
d1:16:09:b2:97:44:43:99:d6:13:19:20:ef:92:9e:
6e:41:44:56:32:c8:1c:5b:54:48:38:6b:5d:c5:00:
a4:62:be:7e:51:76:26:f6:5b:9c:e0:ed:b3:b8:dd:
16:eb:c6:9d:fc:b6:16:c0:60:1a:84:d8:b1:a5:d1:
5d:1f:35:eb:40:08:f0:2b:a1:a8:e8:d0:93:8f:85:
c6:25:a3:63:d0:d8:09:2e:fa:d2:6f:12:73:4e:aa:
ad:6f:c6:cb:b0:24:b4:65:e3:e3:fd:03:f9:d4:64:
07:2a:4b:6b:df:6b:ae:b2:90:eb:7e:57:f0:a8:3e:
08:d1:07:06:e8:04:dc:a6:bd:02:ee:07:97:1f:cf:
41:2c:8a:b0:15:bc:de:c9:13:b9:0a:8f:38:78:4c:
03:d1:46:36:e6:54:e4:3b:5f:eb:f4:02:14:82:09:
d9:0e:60:ea:29:b4:e3:7e:81:8d:4c:81:ee:4b:6d:
6e:a8:7f:f5:79:39:21:20:01:eb:77:4d:ea:22:d8:
15:13
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 Key Identifier:
C0:43:06:E9:20:B5:1E:51:86:CF:27:BB:3B:91:D5:0B:AE:F8:99:A6
X509v3 Authority Key Identifier:
keyid:8A:74:7F:AF:85:CD:EE:95:CD:3D:9C:D0:E2:46:14:F3:71:35:1D:27
Authority Information Access:
OCSP - URI:http://ocsp.pki.goog/gts1c3
CA Issuers - URI:http://pki.goog/repo/certs/gts1c3.der
X509v3 Subject Alternative Name:
DNS:www.google.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.11129.2.5.3
X509v3 CRL Distribution Points:
Full Name:
URI:http://crls.pki.goog/gts1c3/QqFxbi9M48c.crl
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 7D:3E:F2:F8:8F:FF:88:55:68:24:C2:C0:CA:9E:52:89:
79:2B:C5:0E:78:09:7F:2E:6A:97:68:99:7E:22:F0:D7
Timestamp : Sep 13 05:06:59.644 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256 <<#2
30:45:02:21:00:84:00:48:E0:6F:E9:0F:D7:AF:A6:67:
22:C8:D3:D3:A8:E4:FB:38:11:3E:5B:C2:EF:AC:E2:54:
7A:94:AC:1A:47:02:20:1E:84:FB:69:49:C2:1B:2E:0B:
84:8C:AD:CA:13:FF:97:19:3C:57:8A:0A:AC:23:DD:61:
C2:AB:7F:07:46:45:65
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 94:20:BC:1E:8E:D5:8D:6C:88:73:1F:82:8B:22:2C:0D:
D1:DA:4D:5E:6C:4F:94:3D:61:DB:4E:2F:58:4D:A2:C2
Timestamp : Sep 13 05:06:59.161 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256 <<#3
30:45:02:21:00:D5:16:13:47:CE:39:C6:60:AF:11:24:
61:A3:D3:B6:50:BF:32:01:0D:6F:5F:5F:2E:37:E4:F8:
1E:60:9E:70:E6:02:20:09:6A:39:F4:15:FC:36:6C:5F:
9B:C7:E1:B5:48:64:7F:BC:FD:36:6E:1D:7B:E5:74:6A:
55:B0:6E:0F:AF:CF:FF
Signature Algorithm: sha256WithRSAEncryption <<#1B
3a:11:f4:ac:db:fe:63:eb:40:ae:09:4e:d2:3a:89:90:37:c2:
bd:f5:bf:8e:69:7b:48:4e:33:6a:35:46:35:50:bc:94:2e:c3:
87:b4:66:e4:d6:bd:2f:98:99:d4:ba:0f:56:04:de:20:44:86:
61:35:50:3f:66:95:fc:4a:2a:69:b7:3b:0c:70:0f:17:cc:60:
a4:fe:1d:b3:f8:90:0c:b9:fa:3d:69:d0:2f:a9:15:91:cd:89:
bb:92:7d:f5:c6:7f:2f:b8:89:0a:95:f3:71:93:1c:52:77:22:
e8:af:54:f1:b2:0f:9c:4f:9b:28:59:c4:de:ed:63:0f:7b:06:
69:ac:af:5d:bd:1c:52:ca:67:3a:db:52:10:f3:16:55:20:dd:
db:4c:e7:93:e5:d1:56:d1:1f:07:12:0c:da:8c:df:c8:d7:91:
98:5c:c2:f7:f4:dc:ff:66:6b:35:95:f8:b9:cc:cd:1d:0b:cf:
d1:99:5e:ce:1a:d9:97:f3:c5:85:65:e0:17:b9:88:c6:1e:5f:
51:01:97:21:4e:49:6b:a6:ed:3d:df:8d:95:b5:be:54:5a:e4:
58:0d:4c:50:64:5f:47:91:48:45:d4:2b:37:50:bf:d5:fb:cd:
54:f3:c5:a2:72:38:fd:44:da:f9:6f:6a:2a:45:2c:ac:c5:a5:
37:3f:e8:fe
#1A and #1B are the algorithm of the signature on the cert by the issuer, which is in the block following #1B. Yes, there are two copies of this AlgorithmIdentifier in the ASN.1 structure, at the places shown, because X.509 was designed back in the 1980s and people then were concerned about algorithm substitution attacks based on experience with symmetric/secret-key systems, which turned out not to be a significant problem for asymmetric/public-key systems. It is SHA256withRSA because the issuing CA, GTS CA 1C3, uses an RSA (2048-bit) key. Edit: found crossdupes https://security.stackexchange.com/questions/24788/signaturealgorithm-vs-tbscertificate-signature and https://security.stackexchange.com/questions/114746/why-is-the-signature-algorithm-listed-twice-in-an-x509-certificate .
#2 and #3 are the algorithms for signatures on the two Signed Certificate Timestamps (SCTs) embedded in the certificate to support Certificate Transparency. You can see each one is part of an indented block under a heading Signed Certificate Timestamp:. The SCTs are created and signed by various transparency log systems, identified by their logid, and the two log systems GTS CA 1C3 chose to use happen to both have used ecdsa-with-sha256 signatures with P-256 keys. (We can directly see only that the R,S values are 256 bits corresponding to some curve group with a 256-bit order, but RFC6962 confirms that the only acceptable ECDSA curve is P-256.)
Aside: I don't understand why you thought it necessary to black-out some information from a certificate that everyone in the world can easily get and look at. The entire purpose of a certificate (at least an Internet server certificate) is to be publicly known to everybody.

Is there a way to check if a certificate is client cert or server cert?

I received a new keystore .jks file for ssl connection to replace an old, but working, .jks keystore file, but I got "unexpected handshake message: serve_hello" error. I was told to make sure the keystore contains a client cert, so I used keytool to export its cert to a pem file, then use openssl to check the purpose. The result shows
Certificate purposes:
SSL client : No
SSL client CA : No
SSL server : Yes
SSL server CA : No
...
However when I applied the same process to check the old but working jks file I got the same result. Wonder if this is the right way to verify the certificate? And how to troubleshooting this handshake error with the new jks file?
Thanks!
The extended key usage extension contains OIDs which define the purpose:
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
-- TLS WWW client authentication
-- Key usage bits that may be consistent: digitalSignature
-- and/or keyAgreement
https://datatracker.ietf.org/doc/html/rfc5280 Page 44
See: https://oidref.com/1.3.6.1.5.5.7.3.1 and https://oidref.com/1.3.6.1.5.5.7.3.2
When opening a certificate on Windows you can see the extension here:

PHP imap_open(), OpenSSL, and no Cipher

I have moved a PHP script to another server, and now fail to login to an IMAP (TLS) postbox:
TLS/SSL failure for mail.servername.de: SSL negotiation failed
It seems that the problem is caused by OpenSSL, because when I try to connect to the Mailserver from both servers, I get a connection in one case (the mailserver asking for input), but none in the other (the connection is closed, I am back to bash):
openssl s_client -crlf -connect mail.servername.de:993
The most obvious difference is here:
verify return:1
---
<snip>
-----END CERTIFICATE-----
subject=/CN=mail.servername.de
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 3398 bytes and written 483 bytes
Verification: OK
---
New, TLSv1.2, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
And on th other server (where no connection is made)
verify return:1
depth=0 CN = mail.servername.de
verify return:1
140410888582464:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2149:
---
<snip>
-----END CERTIFICATE-----
subject=CN = mail.servername.de
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
---
SSL handshake has read 3167 bytes and written 318 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Server public key is 2048 bit
On the mailserver dovecot is configured not to accept non-encrypted connections. But, I assume it already fails due to dh key too small, which seems to relate to cipher negotiation.
Now I simply fail to put the things together... Why does the SSL connection work from one server, but not from the other?
As I own the "remote end" myself, I was able to increase security. The solution is simple, and may be relevant for others as well ...
The dovecot version is 2.2.x, which is of some relevance for the DH parmaters (see Dovecot SSL configuration). In the configuration file /etc/dovecot/conf.d/10-ssl.conf you can simply add this line:
ssl_dh_parameters_length = 2048
And eventually, it may be necessary to add this here to the main configuration file /etc/dovecot/dovecot.conf at the end:
!include conf.d/*.conf
Finally, it is important not to reload, but to restart dovecot.
systemctl restart dovecot
And suddently, the weight, troubles, and frustration of several hours is gone. Great...
Further to the above, there's a change from dovecot 2.3.
ssl_dh_parameters_length is now not used, and ssl_dh must be used instead, to point to a file generated using
openssl dhparam 4096 > dh.pem
see https://doc.dovecot.org/configuration_manual/dovecot_ssl_configuration/ and scroll down to SSL Security Settings. That was the only change I had to make following the upgrade to get it to work properly again. I put the dh.pem file in /etc/dovecot, so my line in 10-ssh.conf is
ssl_dh=</etc/dovecot/dh.pem
TL;DR: your new host has a newer version of OpenSSL probably with higher security settings which prohibit connecting to the host for reasons explained below.
"dh key too small" comes from OpenSSL and because of too low security.
Things changed, and for example in newest Debian versions and with OpenSSL 1.1.1 (and I guess it is similar for newer versions), the security was enhanced.
The best and simplest explanation I have found is on Debian wiki at https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1
which says:
In Debian the defaults are set to more secure values by default. This
is done in the /etc/ssl/openssl.cnf config file. At the end of the
file there is:
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT#SECLEVEL=2
This can results in errors such as:
dh key too small
ee key too small
ca md too weak
Now the possible solutions in descending order of preference:
ask the remote end to generate better "DH" values ("Server Temp Key: DH, 1024 bits"); the best explanations are at https://weakdh.org/sysadmin.html; note specifically the "Administrators should use 2048-bit or stronger Diffie-Hellman groups with "safe" primes."
configure your end specifically for this connnection to not use the OS default and lower your settings; it should be enough to set ciphers to "DEFAULT#SECLEVEL=1" in the code that does the connection
(really, really, really not recommended) change the value of SECLEVEL from 2 to 1 in the global configuration file on your end. But this impacts all connections from your host not just this one so you are lowering the global security of your system just because of one low level of security from one remote node.

Why does verify smime signature fail?

I've got an email with a signature which I'm trying to verify.
I am using openssl
openssl smime -inform SMIME -CAfile all.pem -verify -in signed.eml
to check, which gives errors:
4144:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:142:
4144:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object header:tasn_dec.c:1302:
4144:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:379:Type=X509_SIG
4144:error:21071069:PKCS7 routines:PKCS7_signatureVerify:signature failure:pk7_doit.c:978:
4144:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:pk7_smime.c:312:
After googling around for some time, this first seemed to be an error with the asn.1 structure. But running openssl asn1parse -i -in sig.txt (sig.txt being only the signature from signed.eml from before) gives no errors and shows the ASN.1 tree (IMHO) nicely.
And as a sidenote: the email is shown as successfully verified in MS Outlook 2010.
Any ideas what could be wrong with the signature or which pecularities of openssl I'm hitting here? Any other tools besides openssl to check the signature (to rule out an openssl problem)?
Ok, so with help from the openssl mailing list:
It is an error with the asn.1 structure. The signature was malformed. That wouldn't cause problems with asn1parse but would when OpenSSL tried to verify it.
It didn't have a proper DigestInfo structure but just the raw SHA1 hash, which violates the RSA scheme mentioned in the PKCS#1 specification.
Outlook (and other clients) seem to tolerate the raw form, whereas openssl (and Thunderbird and other clients) don't.

Keep the push.php file and test APNS connection using MAMP?

Am following these tutorials to enable Apple Push Notification Server to send Notifications to device.
http://www.raywenderlich.com/3525/apple-push-notification-services-tutorial-part-2
From this tutorial I downloaded MAMP and "created the database to store the users details" and also I have "downloaded the PushChatServer folder from the tutorial". I stored the UDID, Device Token (from APNS), Name, Code in the database. Now I want to send Push Notifications from my localhost.
I am keeping the .pem file, push.php, push-confi.php on my desktop. From the tutorial this part I don't understand:
In the PushChatServer directory there is a push folder that contains the PHP scripts you need to send out push requests. You should put these files in a directory on the server that is not accessible from the web, in other words outside of your DocumentRoot. This is important because you don’t want visitors to your website to download your private key! (In our MAMP setup, this is already taken care of.)
The most important script in the push folder is push.php. This script should be run as a background process on your server. Every few seconds it checks if there are new push notifications to be sent out. If so, it sends them to the Apple Push Notification Service.
First, we need to edit the file push_config.php, which contains the configuration options for push.php. You may need to change the passphrase for the private key and possibly the database password.
As with the server API, the push script can run in either development mode or production mode. In development mode, it talks to the APNS sandbox server and it uses your development SSL certificate. You should use development mode in combination with Debug builds of your app. Production mode should be used for Ad Hoc and App Store builds of your app.
Where I want to keep my Push folder in my Mac. How can I check the APNS connection?
I placed the Push folder(Which is contains the Push.php) in my directory to read from Terminal. And also I pasted the Application folder in my directory.
Tutorial said to use this command in Terminal
$ /Applications/MAMP/bin/php5.2/bin/php push.php development
But, in MAMP I have this path
/Users/creagx/Applications/MAMP/bin/php/php5.5.17/bin/php
Where I need to place the Push folder and MAMP.
I kept my .pem files and push.php files in this path: /Users/gopi/Desktop/APNSsample/push.php
Then I have tried to connect my .pem (SSL) to APNS using Terminal app like this
unknownc42c032e8297:~ name$ cd /Users/creagx/Desktop/APNSsample
unknownc42c032e8297:APNSsample name$ telnet gateway.sandbox.push.apple.com 2195
Trying 17.149.34.66...
Connected to gateway.sandbox.push-apple.com.akadns.net.
Escape character is '^]'.
^C
Connection closed by foreign host.
unknownc42c032e8297:APNSsample name$ openssl s_client -connect gateway.sandbox.push.apple.com:2195 -cert NameAPNCert.pem -key NameAPNKey.pem
Enter pass phrase for NameAPNKey.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=Internet Services/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-----
MIIEZTCCA02gAwIBAgIESyDhfjANBgkqhkiG9w0BAQUFADCBsTELMAkGA1UEBhMC
VVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0
Lm5ldC9ycGEgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMW
KGMpIDIwMDkgRW50cnVzdCwgSW5jLjEuMCwGA1UEAxMlRW50cnVzdCBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eSAtIEwxQzAeFw0xMDA0MTMyMzM0MzNaFw0xMjA1MzEw
MDA0MjdaMIGPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAG
A1UEBxMJQ3VwZXJ0aW5vMRIwEAYDVQQKEwlBcHBsZSBJbmMxGjAYBgNVBAsTEUlu
dGVybmV0IFNlcnZpY2VzMScwJQYDVQQDEx5nYXRld2F5LnNhbmRib3gucHVzaC5h
cHBsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM5NngiDMFpGBMmb
8tG2MRhLEdsx553Xjq+5C/c0mtildwhnC1X0LWKUexWdQsMchniac+WnHFSs3YMJ
JJ55kQSB6wqK/WNcxsUn8pMkMsvk3YZFM7TsaKQvFOeieiXCSJVlR3grm3+dilv1
Br+SUqv8JrgU3ijmoQO63vkb8B/hAgMBAAGjggEnMIIBIzALBgNVHQ8EBAMCBaAw
HQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMDMGA1UdHwQsMCowKKAmoCSG
Imh0dHA6Ly9jcmwuZW50cnVzdC5uZXQvbGV2ZWwxYy5jcmwwMwYIKwYBBQUHAQEE
JzAlMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5lbnRydXN0Lm5ldDBABgNVHSAE
OTA3MDUGCSqGSIb2fQdLAjAoMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LmVudHJ1
c3QubmV0L3JwYTAfBgNVHSMEGDAWgBQe8auJBvhJDwEzd+4Ueu4ZfJMoTTAdBgNV
HQ4EFgQUNyg/64Sjw/+b4YOwC8E/c+jemRgwCQYDVR0TBAIwADANBgkqhkiG9w0B
AQUFAAOCAQEAk9Ij+NCp+323+4vBqbA0fT9ZCROptPqNIshY5uEvaWUaW5hsoLUm
fsMJMueqzDaoj4yPD8iCCZq1Mp8tM8WB2mG1zIxTLshlhRgDDUF11IbUUBHv/ZhU
RzXewQD6pazQmsBPuR0vP3mmWbKqmZOiv2yWSGlQmWGW4m6RQwjYYj8UqqFEdinV
g1+qY6/muTpaCiygDjJZBlv9P6bwwP9FB8OJf5tGECvvxXad3PK/oiI77aLTYSVr
SA0oisXCiqcgTKQq5BV5M3fQQ4ZS73aBKLI0wPYc0AASD5WdtPTGTvmEbhO4KeaU
0SL85Prf8uSsDOLvn3656awLz/H/yzrf/g==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Cupertino/O=Apple Inc/OU=Internet Services/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 2549 bytes and written 2017 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID:
Session-ID-ctx:
Master-Key: 729CC0899B36143DAC78D40B2C31ECB71C81A3BD8DC5CFD6D71AC7885DD2E63DCD47096E97A1B3AF032A8D7D48BF73DA
Key-Arg : None
Start Time: 1336636910
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
name
closed
unknownc42c032e8297:APNSsample name$ php push.php
Usage: php push.php development|production
unknownc42c032e8297:APNSsample name$ development
-bash: development: command not found
unknownc42c032e8297:APNSsample name$ php push.php development
I have received the APNS connection status in push_development.log like this,
2012-05-10T13:32:34+05:30 Push script started (development mode)
2012-05-10T13:32:34+05:30 Exiting with fatal error: exception 'PDOException' with message 'SQLSTATE[HY000] [2002] No such file or directory' in /Users/name/Desktop/APNSsample/push.php:82
Stack trace:
#0 /Users/creagx/name/APNSsample/push.php(82): PDO->__construct('mysql:host=loca...', 'pushchat', 'name', Array)
#1 /Users/creagx/name/APNSsample/push.php(36): APNS_Push->__construct(Array)
#2 {main}
I can't understand what I did wrong? I am using the database from MAMP. I have stored the devicetoken, messages (Payload) in MAMP SQL database.
Terminal:
unknownc42c032e8297:~ gopi$ cd /Users/gopi/Desktop/APNSsample/
unknownc42c032e8297:APNSsample gopi$ php push.php
Usage: php push.php development|production
unknownc42c032e8297:APNSsample gopi$ php push.php development
unknownc42c032e8297:APNSsample gopi$
In my push_development.log file:
2012-05-10T16:08:12+05:30 Push script started (development mode)
2012-05-10T16:08:12+05:30 Exiting with fatal error: exception 'PDOException' with message 'SQLSTATE[HY000] [2002] No such file or directory' in /Users/gopi/Desktop/APNSsample/push.php:82
Stack trace:
#0 /Users/gopi/Desktop/APNSsample/push.php(82): PDO->__construct('mysql:host=loca...', 'pushchat', 'gopi', Array)
#1 /Users/gopi/Desktop/APNSsample/push.php(36): APNS_Push->__construct(Array)
#2 {main}
After you copy both of the .pem files to the same directory(in case desktop).Paste the following codes in terminal:
' cd /Users/gopi/Desktop/APNSSample/ '
Hit enter and you should get no erros,just a new line in Terminal.Now to test the connexion,paste the following code in terminal after you pasted the other one:
' php yourphpfile.php '
Hit enter and you should get three lines of code seying that the php file were able to reach the APNS Server.If it works,you're ok,else tell me!