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-----
...
Related
I have established kubernetes cluster on one of the private hosting machine with public IP. I installed a few applications there and NGINX as the ingress controller. I would like to make a reachable my services outside of the cluster and be accessible with the specific domain. I installed cert-manager via helm and requested certificate via letsencrypt-prod, (validated domain via http-01 resolver) everything looks perfect (clusterissuer. certificate, certificaterequest, challenge) but from some reason, my TLS secret after BASE64 decoding - contains three certificates in the following order:
-----BEGIN CERTIFICATE-----
XXXX
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
XXXX
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
XXXX
-----END CERTIFICATE-----
which is incorrect, as far as I know - it should be only two certificates (instead of 3), any ideas what can be wrong with that?
There's nothing wrong with it. You are seeing the root certificate, intermediate certificate, and your subscriber certificate.
It's actually normal for certificate authorities to use intermediate certificates.
You can read about it here: https://letsencrypt.org/certificates/
My question is very short: how does the process look like to retrieve a ca certificate for an existing Kubernetes cluster to connect gitlab with this cluster?
After studying the docs, everything is fine, but I don‘t understand which cluster certificate is meant.
Many thanks and have a nice day everyone!
In this gitlab documentation you can find instructions how to add an existing cluster to the gitlab and what do you need to do so.
CA certificate (required) - A valid Kubernetes certificate is needed to authenticate to the cluster. We use the certificate created by default.
This is a certificate created by default inside the cluster.
All you have to do is get it and this is written in following steps:
i. List the secrets with kubectl get secrets, and one should be named similar to default-token-xxxxx. Copy that token name for use below.
ii. Get the certificate by running this command:
kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode
If the command returns the entire certificate chain, you must copy the Root CA certificate and any intermediate certificates at the bottom of the chain. A chain file has following structure:
-----BEGIN MY CERTIFICATE-----
-----END MY CERTIFICATE-----
-----BEGIN INTERMEDIATE CERTIFICATE-----
-----END INTERMEDIATE CERTIFICATE-----
-----BEGIN INTERMEDIATE CERTIFICATE-----
-----END INTERMEDIATE CERTIFICATE-----
-----BEGIN ROOT CERTIFICATE-----
-----END ROOT 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.
We use ServiceNow to communicate with PushBullet via REST API. Recently we started getting the following error
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
And a 500 HTTP error.
After much research it appears SNI has been added as part of an SSL certificate upgrade https://en.wikipedia.org/wiki/Server_Name_Indication
ServiceNow state they do not support SNI in any version.
The tests that you see are from SoapUI and Postman.
The way we test for this is by using the following command:
openssl s_client -connect api.pushbullet.com:443
(this fails)
Adding the -servername parameter is used to pick the correct domain from the certificate that now contains multiple domains:
openssl s_client -connect api.pushbullet.com:443 -servername api.pushbullet.com
CONNECTED(00000003)
depth=1 /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G2
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/CN=*.pushbullet.com
i:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G2
1 s:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G2
i:/C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGbDCCBVSgAwIBAgIQTyKV1VxdJTcntEU7ErB0mjANBgkqhkiG9w0BAQsFADBH
<snip>
Is there any way of now accessing PushBullet APIs without SNI?
Gavin.
SNI support has been added as of the Jakarta release:
https://docs.servicenow.com/bundle/jakarta-servicenow-platform/page/integrate/outbound-web-services/concept/outbound-sni-support.html
By default, SNI support is disabled in Jakarta. If it has been enabled on your ServiceNow instance, you would have the glide.outbound.tls_sni.enabled property set to true. Change it to false and your API calls should stop using SNI.
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.