I followed the instructions at:
How To Build An Apple Push Notification Provider Server
When I run the php script on my MacOSX or on Windows using Parallel desktop, the script works. But as soon as I run it on my hosting I get the message:
Warning: stream_socket_client() [function.stream-socket-client]: unable to connect to ssl://gateway.sandbox.push.apple.com:2195 (Connection timed out) in provider.php on line 23
Failed to connect 110 Connection timed out
Does this have to do with the certificates? If so how can I make a certificate that could work on the computer where my hosting is located.
Your hosting provider probably does not allow outbound connections to ports 2195 and 2196. Most shared hosting providers do not have those ports open. You might need to get a VPS or you can also try UrbanAirship which provides Apple Notification Service integration and is free for a certain limit per month.
Yes you need a certificate. THis is explained in the Apple docs. One catch, you will probably need to convert the cert to .pem format. The .pem cert needs to include both the certificate and the RSA private key.
Here is a good site to read: http://www.macoscoders.com/2009/05/17/iphone-apple-push-notification-service-apns/
My pem looks like:
Bag Attributes
friendlyName: Apple Development Push Services: <my data>
localKeyID: <my local key in hexascii>
subject=/UID=com.my.push.sandbox1/CN=Apple Development Push Services: <my data>/C=US
issuer=/C=US/O=Apple Inc./OU=Apple Worldwide Developer Relations/CN=Apple Worldwide Developer Relations Certification Authority
-----BEGIN CERTIFICATE-----
<my certificate data omitted>
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
<my key data omitted>
-----END RSA PRIVATE KEY-----
I found the simplest and cheapest solution was to request a dedicated IP from your hosting company. At Blue Host it was $2.50 a month. With this dedicated IP, they were willing to open ports 2195 and 2196.
Related
I am following the installation docs for the new IPI install of OpenShift 4.5 on vCenter and running into a snag when trying to connect to the vCenter. I am running the installer from a CentOS 7 box.
[root#lb ocp45_install_2]# openshift-install create install-config
[...]
INFO Connecting to vCenter [myvcenterhere]
FATAL failed to fetch Install Config: failed to fetch dependency of "Install Config": failed to fetch dependency of "Base Domain": failed to generate asset "Platform": unable to connect to vCenter [myvcenterhere]. Ensure provided information is correct and client certs have been added to system trust.: Post https://[myvcenterhere]/sdk: context deadline exceeded
I have added the root certs for my vcenter into /etc/pki/ca-trust/source/anchors/ per the documentation and I am able to reach it over 443 when using netcat. I also verified all login info was correct.
I have previously used this machine to do a UPI install of 4.3 in the same vCenter and did have success connecting. The vCenter uses a self-signed certificate.
Does anyone know if I need to include anything special to allow it to use the self-signed certificates when creating the install-config.yaml after adding the certs to the system trust?
You can try inserting that self-signed certificate into your nodes trust store.
This can be done editing your install-config.yaml, adding an additionalTrustBundle definition. Doc mentions:
apiVersion: v1
baseDomain: my.domain.com
additionalTrustBundle: |
-----BEGIN CERTIFICATE-----
<MY_TRUSTED_CA_CERT>
-----END CERTIFICATE-----
...
I'm trying to use Insomnia with Client Certificates. I followed this document from the Insomnia documentation. I added my certificate pem files and password.
The problem is that I'm still getting this error:
Error: Couldn't connect to server.
Do you have any idea why? Thanks.
Insomnia seems rather strict in the rules to apply the client certificate.
For example, if you connect to localhost:5050 you should put localhost:5050 as the host. Localhost as such does not work in this case.
Key + Certificate is also the safest way to get working results. I've noticed a number of cases where the encapsulated certificates (PFX) didn't work but the key + certificate file did. I assume that this is related to the way the pfx-certificates are created because it also applies for the browsers I test with.
I was able to consume an extremely and rare service using insomnia version 2021.4.1. I could not consume it with Soapui nor Postman.
I followed these easy steps. It worked at first attempt :D, just the p12 file was enough on my case.
Importing Certificates with Insomnia
I will put here the official documentation, in case the link disappears:
Insomnia supports PFX (Mac), and PEM (Windows and Linux) certificates. To import a new certificate, open the Document/Collection Settings dialog – accessible from the top-left menu – and click on the Client Certificates tab. From here, you can add new certificates and view existing ones.
Now lets walk through how to import one.
If you’re familiar with client certificates, the only field needing explanation should be the Host field.
Host: certificate will be sent when the host (and port if specified) matches
PFX: certificate in PFX or PKCS12 format (Only supported on Mac)
CRT File + Key File: certificate and key pair (only supported on Windows and Linux)
Passphrase: An optional passphrase for the certificate if required
After importing a certificate, it will show up in the main certificates list. From here, it can be enabled/disabled or deleted.
Insomnia is very strict about self-signed certificates.
I had a similar issue on a Windows environment with Insomnia version 2022.2.1.
My solution was to add the intermediate and root certificates as well to the client certificate (.crt) file with the following order:
-----BEGIN CERTIFICATE-----
client cert
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
intermediate cert
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
root cert
-----END CERTIFICATE-----
Then I imported the client certificate .crt file and .key file for the host and it worked.
Mojolicious lets me specify an ssl certificate and key when starting the app:
> ./myapp.pl prefork --listen 'https://*:8485&cert=my.crt&key=my.key'
I am trying todo this with a rapidssl certificate.
Connecting to this service results in wget being rather unhappy:
$ wget https://example.com:8485/
--2016-06-22 09:50:49-- https://example.com:8485/
Resolving example.com (example.com)... 1.3.2.4
Connecting to example.com (example.com)|1.3.2.4|:8485... connected.
ERROR: cannot verify example.com's certificate, issued by `/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3':
Unable to locally verify the issuer's authority.
To connect to example.com insecurely, use `--no-check-certificate'.
No big surprise, since when using rapidssl certs in other applications I have
to specify an intermediate certificate as well. So I tried to add this here too by concatenating the intermediate cert to the site certificate, but this has no influence on the outcome.
I also tried to put the intermediate certificate along with the root cert into a separate file and start with:
> ./myapp.pl prefork --listen 'https://*:8485&cert=my.crt&key=my.key&ca=myca.crt'
but the result was equally uninspiring:
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
please advise.
If you want the server to send not only the leaf (servers) certificate but also any other (intermediate) certificates to the client then you simply add these to the cert file in the correct order. This means your my.crt should look like this
----BEGIN CERTIFICATE-----
MII... the leaf certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MII... the first intermediate certificate, i.e. the one which signed the leaf cert
-----END CERTIFICATE-----
...
Just got my Lync server deployed on Windows Server 2008 R2 and am trying to connect via Lync client on a different machine. When attempting to sign in, the client throws an error saying "Cannot sign in to Lync: There was a problem verifying the certificate from the server.".
Looking deeper, into the client box's event viewer, I see the following error "The certificate received from the remote serer was issued by an untrusted certificate authority. Because of this, none of the data contained in the certificate can be validated. The SSL connection request has failed. The attached data contains the server certificate. ....
My organization has an internal CA, which is in charge of issuing all required certificates to the Lync server. My client box has installed the internal CA (root) as a trusted CA provider. To me, this should cause any certificates that issues, including the Lync certificates, to be trusted.
I installed Lync client on the same box that Lync server is hoted, and am able to log in fine. My error only occurs when connecting from a different box.
Can anyone shed some light? Thanks!
I had same issue. To resolve: from client, hit url of CA Authority, some thing like http://CAservername/certsrv this provided option to download a CA Certificate Chain.
Put this into local computer trusted root certs and I was good to go.
As mentioned in the error message ("Cannot sign in to Lync: There was a problem verifying the certificate from the server"), this is clearly a certification error. If you work in a big company (where they have they own internal CA - (Certification Authority)) in most cases they would have used their internal certificate to establish trust relationship. If you just install/export the Root certificate of the CA under "Trusted Root Certificate Authorities” of “Local Computer” account, this error should be resolved.
If your company doesn't have own CA, then find our who issued the certificate for Lynch and install/export the root certificate of that CA to the same location as above, this issue should be resolved.
I've godaddy's 2048bit certificate for domain and 4 subdomains.
[www.site.com, mail.site.com, e.t.c.]
Standard Multiple Domain (UCC) SSL Up to 5 Domains - 1 year (annual)
That certificate works fine in Apache, ssl web checker says OK and browser shows green line in address string.
I've added this certificate to mail daemon, it has been accepted by Exim too.
When some client tries to send mail with SSL/TLS connection through mail server, mail program says "Certificate is BAD" though shows correct trusted info.
Client connects to hostname: mail.server.com, server's hostname is: ns1.server.com (not added to certificate), mail server says: 220 ns1.site.com ESMTP Exim 4.73
Mail clients tested: iPAD mail client, Mozilla Thunderbird, Mac mail client
Please help.
UPDATE:
Godaddy's ssl checker says: SSL Chain of Trust is Broken!
Here are a couple of things to check:
Is the hostname that the mail client uses in the TCP connect, listed in the server certificate as the Common Name (CN) of the subject distinguished name?
If not, is it listed using type "DNS:" in the Subject Alternative Name X509 v3 certificate extension?
If neither of the above, you might be getting "Remote Certificate Name Mismatch" (or similarly named error.)
If it is listed, then look for the Issuer of the certificate, and Issuer of the Issuer, etc., all the way to the root certificate of the chain. The root certificate should be installed on the client machine, in the "Trusted Root" certificate store for whatever client you are using (Windows, Mozilla, Java keystore, etc.)
If the root certificate is installed, then look at the intermediate certificates, if there are any in the chain (between root and server certificates). They have to either be installed locally, or arrive from the server alongside the server certificate -- either the server sends them each time or you've got the intermediate certificates already installed on the client end. Either way, they have got to be in hand to accept the server certificate.
Do the clients which reject the certificate have the appropriate root certificates in their cert store?