We need to setup an EDI AS2 connection with a trading partner who doesn't accept self signed certificates. As far as I know AS2 uses S/MIME certificates also known as email certificates, right?
I assume all I need is to buy an email certificate from a trusted authority like SwissSign or Digicert. But I wasn't able to find any related product to AS2. Furthermore I'm confused if buying an email certificate is the right way, because in EDI AS2 communication there is no email address.
Has anyone experience with this and can point me to the right product/certificate to buy?
It isn't an "email certificate" it is an X.509 certificate that you use to sign your messages with. I think you got confused because it mentioned MIME, which is used in email, but isn't exclusive to that. It is the same as a certificate that you can use for SSL, but with AS2 people usually don't worry about getting a CA one, as it is cheaper to self generate and send your trading partners the public key so they can verify you as the sender.
See AS2: Part 3 – Certificates
With AS2 we do not need a CA to trust the authenticity of the other party, because we have already secured its public certificate through another channel. This means it is a waste of time and money to get your AS2 public certificate signed by a CA.
Possibly if you company already has a certificate used for a web site of your company, you could potentially just use that for your AS2 as well.
Related
I'm studying Azure IoT Hub and trying to connect my device to IoT Hub with x.509 certificate.
It worked with self-signed cert, but the official suggestion is to purchase a root CA cert from a trusted third party to sign device cert.
Get an X.509 CA certificate
I did some research, but couldn't find where to purchase.
Can you give me a link? And how much will it cost?
You probably don't want a root CA cert, as those are not available to anyone but the certificate authorities themselves.
What you seem to be looking for, is a certificate signed by a root CA.
You can get one from let's encrypt, or from any of the commercial CAs like Verisign, Thawte, etc.
A word of warning. If you purchase a certificate from a certificate authority that has been signed by a trusted root and you intend to use that to sign device s' X.509 certificates for authentication, make sure that you do not purchase an end entity certificate. That type of certificate is incapable of signing another certificate and will not work. Make sure the certificate you get is capable of signing other certificates.
AWS has it's own CA. Because AWS thinks security is important and they are capable of a decent cloud product implementation.
Microsoft on the other hand is more worried about selling defender security E5 licenses, so security implementations are weak or require premium licenses. No account expiring, no Azure CA for devices.
This 3th party can fix your problem for IOT Hub.
https://www.globalsign.com/en/blog/integrate-microsoft-iot-azure-iot-hub-and-provisioning-service
https://www.deviceauthority.com/solutions/keyscaler-identities/
https://www.keyfactor.com/platform/iot-identity-platform/
I have to develop a web application that is both secured over https and uses client authentication certificates. The clients are connecting via invitation, thus it is not intended for users stumbling upon this application by googling around.
The ideal would be to get an intermediate CA certificate form a public root authority and sign both the ssl certificate and use it to issue client authentication certificates. I think that won't work, as simply put I will never qualify for such an intermediate CA (as far as I know, but maybe I am wrong with that).
Second guess: create own Root CA, an intermediate CA and use them. Because of what I wrote about the users, I can embed the necessary certificate chain in the issued certificates. This technically works.
What I would prefer is to get an ssl certificate from public authority and to use my own chain to issue authentication certificates and verify the users. According to this it is possible. But I haven't found anything about how to configure IIS for example (or Kestrel) to request client certificates issued by a specific CA, even less some standard specification where this flow is described.
I have an architecture where there is a single root CA and multiple sub-CA's. Each sub-CA publishes certificates for devices in it's "domain". Within each domain is a VPN gateway (Cisco router). I would like to determine if it is possible to devise a configuration where each domain's VPN gateway would be able to check to see if the connecting device's certificate has been revoked at it's domain's sub-CA or another of the other domain's sub-CAs. I'm also looking for the most efficient solution which would require as little configuration as possible when adding new domains.
Thanks!
A CRL or OCSP response has the serial number of the revoked certificate in a list, which is signed by the issuing CA or OCSP responder. This ensures that when I revoke certificate serial no 123456789 on my CA that the certificate with the same serial number but issued by your CA isn't revoked instead. Certificate serial numbers, although long, aren't globally unique.
From a security perspective, the ability to revoke another CA's certificates would just cause mayhem and the consequences would be dire.
The only CA that can revoke a certificate is the one that issued it.
I would ask for help in this matter.
I work in a software company and we're writing a client-server application (like system of documents circulation). It will be delivered as a complete solution as two distributions: client and server.
One of the requirements is the client and server must exchange information in encrypted form.
We decided to use SSL, but have some questions:
If we use self-signed certificates then we must generate certificate pair on server side, but how does the client know the server certificate? I want to install all required certificates during installation, but the server certificate is defined only on server installation.
If we ship client and server installer with wired server root certificate signed our company certificate in server and client installer - then our company client may create new certificate signed certificate that sign out certificate, that is chain with our company certificate in root - that is bad.
How can we solve this problem?
I want to ship to client 2 distributions: client, server and after installation they may establish secure channel to exchange information and user should not need to install any certificate manually.
Noticeable, this is completely product, we want to sell them to different companies and these companies must have different certificates.
I have a mobile app that will be communicating with my webserver over https. My question is, do I even need to worry about installing a certificate since all traffic to this api will be headless?
In my understanding, SSL provides the encryption for a request, and a certificate establishes trust for the end user. Because these calls to my webserver will essentially be headless, I'm thinking I don't need to worry about the trust establishment.
Am I correct in this thinking?
You will either need a self-signed certificate or a CA-signed certificate in order to use HTTPS on your server.
If your certificate is not assigned to you by a certificate authority, then any connection you make will trigger an error in your URLRequest that you will have to handle. The problem with an untrusted certificate is that a malicious man-in-the-middle could fake data to and from your server with his own self-signed certificate, and possibly pick up authentication credentials or data that he should not have access to.
If you are dealing with any authentication credentials or other private data, I'd recommend just requesting a signed certificate. If you shop around, you can find cheap signed certificates for $10-20 a year, which is a trivial cost to protect your users.
However, if this is just a personal project (the only data you have to worry about is yours), or any data that you will be sending is freely available, a self-signed certificate may be enough.