Can I use the same keystore and cert for AMS that my app already uses?
You can, but also have the option to use separate certs and/or keystores if you want. The keystore.conf file contains the details of the keystore and the label of the certificate that AMS will use for encrypting and signing messages. This can point to the same certificate as used by the application for making connections to WebSphere MQ, the same certificate the app server uses for SSL connections or an entirely separate keystore dedicated to AMS.
The key (excuse the pun) is to manage the keystores based on the security model required. The app server's keystore probably has a number of external-facing certificates in its trust store. For example, it might trust several commercial certificate authorities. The AMS keystore must contain the certificates of anyone who will be signing or encrypting messages that your app will consume or receiving encrypted messages from your app. Since these are usually internal-facing it might be worthwhile to use a separate keystore for AMS than is used for external-facing entities. Otherwise the two different security models (internal-facing and external-facing) end up trusting each others participants.
This is just one example and in general the idea is to construct the keystores based on the specific security model required and using a least-trust principle. You have to balance the cost of maintaining separate keystores against the extra security of maintaining individual ones.
Related
For this situation I'm using WSO2 Enterprise Integrator 6.4.0
I currently find myself in the situation where I have 1 endpoint (SOAP) controlled by government (which I need to use) and multiple of our end customers need to connect to. In order for this to work, all the end customers need to address the same endpoint in the same fashion but using their own client certificate.
So customer 1 has certificate 1 and customer 2 needs certificate 2, etc.
AS far I as could tell, from documentation and trying, one endpoint can only ever use a single certificate in its connection. Since the amount of customers might change on a daily basis I would to have a single common solution to this problem.
Currently to circumvent this problem I'm creating a design in which I use endpoint per customer and a reverse proxy to connect to the final endpoint. This is however not ideal since I would still need to create 1 endpoint per customer, which might turn out to be pretty intensive.
I'm open to any suggestions.
You are right that you cannot get the ESB to present a different certificate based on the client that is trying to connect. If you really want to go down that route putting a reverse proxy (like nginx) in front of the ESB and using that to handle the SSL could work, but I wouldn't really recommend doing that.
If you are wanting mutual SSL (link, link) then you need to add the certificates of the clients that will be connecting to your endpoint to your client trust store. The default truststore is located at <wso2EI_home>/repository/resources/security/client-truststore.jks. To import a cert keytool -import -trustcacerts -file <cert-file-name> -alias <choose-a-useful-name> -keystore client-truststore.jks The default password is wso2carbon.
Doing this does require you to maintain the certificates, when a client cert changes because it expired you need to import the new one. They won't be able to connect until you do.
Another option could be to disable mutual SSL and have you endpoint open for anyone (that you allow through your firewall) to be able to connect. You won't have to maintain a list of client certificates. The traffic will still be encrypted, you will just lose the tight control over who can connect.
I have been managing Let's Encrypt's SSL certificates for a domain.
Now I am moving to Amazon API gateway. I will be using the AWS Certificate Manager to generate HTTPS certificates for the root domain and a bunch of subdomains.
If I make the transfer, what happens to my current HTTPS certificate which is associated with my domain. If browsers suddenly start seeing a new HTTPS certificate for a domain, for which they had been getting a different HTTPS certificate until now, would this be a problem?
Also, once I make the shift, what do I do with my current (manually managed) Let's Encrypt certificate? Is there a way to permanently void it?
Szabolcs Dombi says
You can have multiple valid certificates for the same domain at the
same time. Moving from one certificate issuer to another should not
cause a problem.
Toby Osbourn says
SSL certificates don’t last forever, most of them need to be renewed
on a yearly cycle and occasionally you will want to change the type of
the SSL certificate mid-cycle.
Since you are replacing certificates, I suggest you to back up the ones you have.
Once you have backed up the old certificates, just overwrite the .crt and .key files with your new ones. Then, reload your web server so it knows to look at these new certificates, and you should be good to go.
If it's within your interest to know more about how to Generate SSL certificate using Amazon Certificate Manager (ACM), I suggest Barguzar, A. (July 2018). Building Serverless Python Web Services with Zappa. where one can read a good step by step guide. See an excerpt of it below:
ACM is a service that manages and creates SSL/TSL certificates for
AWS-based services and applications. An ACM certificate works with
multiple domain names and subdomains. You can also use ACM to create a
wildcard SSL.
ACM is strictly linked with AWS Certificate Manager Private
Certificate Authority (ACM PCA). ACM PCA is responsible for validating
the domain authority and issuing the certificate.
You can have multiple valid certificates for the same domain at the same time. Moving from one certificate issuer to another should not cause a problem.
This also means that if you create a new certificate the old one still can be used unless it already expired.
I'm writing a utility Mac OS X app that basically acts as a web server accepting incoming HTTP requests (think of it as a mock REST API server). I want to be able to support HTTPS, but ideally I'd like to remove the requirement for my users to have to purchase their own SSL certificates.
I've been thinking a little on how I might achieve this. Let's say I register a domain called myapp.com. I then purchase an SSL cert for myserver.myapp.com that is signed by a registered CA. I ship my app with those SSL cert details embedded within it. All my users have to do is update their /etc/hosts file to point myserver.myapp.com to whatever IP address my app is installed and running on.
In fact, by far, the most common scenario would be my app running on the same machine as the client, so I'm considering updating the main DNS entry for myserver.myapp.com to point to 127.0.0.1, and most users wouldn't have to change anything.
So, that's the basic theory. What have I missed that would make this an unworkable plan? A couple of things that have crossed my mind:
I could use a self-signed cert. However, many SSL clients barf (or throw up warnings) if the cert doesn't have a valid CA chain. I'm happy to pay the money for a real cert to alleviate this inconvenience for my users.
I would be embedding the private key for my SSL cert into my app. In theory, someone could extract that and use it to impersonate my app. I guess my reaction is "so what?" My app is a small productivity app, it isn't an e-commerce site. It doesn't collect sensitive info. It literally just simulates web server responses so devs can test their apps.
Any advice/feedback would be greatly appreciated. Thanks.
This won't work - but for nontechnical reasons.
Distributing an SSL certificate to your users along with its associated key will violate the issuance terms of your SSL certificate provider, and they will revoke the certificate when they discover what you have done. (This happened, for example, when Pivotal tried to offer SSL service for developers through sslip.io.) This will, of course, cause your application to stop working.
If your users have administrative access to their machines, they can create and trust their own self-signed CA using Keychain Access. Once they have done so, they could create a certificate (again, using Keychain Access) and insert that into your application to enable SSL.
As said in the other answer you can't ship the same certificate for everybody. What you could do is generate different for everybody:
The application ask them the domain name they want to use (a domain they must own, like myapp.example.com)
The application use the ACME protocol to get automatically a trusted certificate from let's encrypt
Note: you can provide them subdomains of a domain you control (like [clientid].yourappname.yourdomain.com) ONLY of you can register yourappname.yourdomain.com in the public suffix list (because let's encrypt have rate limits)
I Want to authenticate systems deployed on different servers with each others using certificates. If it wasn't a self-signed certificate, what should it be to let each system has its own certificate and trust in in the other server in the production environment?
The signed certificates are paid and I don't think I need them since I don't have user interaction. Am I right?
The distinction here is not really "self-signed" vs "signed." The correct distinction is "commercial" vs. "internal." Commercial certificate vendors are selling you exactly one thing: they have a certificate in the root store of major browsers and operating systems. There is no technical difference between a certificate that Verisign signs and one that you sign. Verisign just has a signing certificate in this list and you don't.
So you're correct. For internal authentication, there is no security reason to favor commercial certificates. You still have to protect your private key just as carefully. Commercial certificates offer convenience, not security. You pay them some money, and you don't have to worry about some of the configuration.
But you can trade convenience for money. There are two ways to do that: internal roots and certificate pinning. With an internal root, you just create some signing root certificate (a "Certificate Authority") and put it in the trusted root stores of your servers. Then issue CSRs (certificate signing requests) to yourself, sign them, and apply those to your services.
Certificate pinning just skips the Certificate Authority step. Just take all of your service certificates, and put them directly into the trusted root stores of your servers. Then there's no indirection.
Each way has its advantages. I tend to prefer pinning all other things being equal because it ties me to specific certs rather than chains. But either way is really fine.
The specifics of course are going to be highly dependent on your toolchain, which you didn't list, but your question suggests you already know how to create the certs.
Just remember that your security is going to be dependent on protecting your private keys. But that was true with commercial certificates, too.
You didn't say what platform you are using, but for Windows I would recommend Active Directory Certificate Services: https://technet.microsoft.com/en-us/windowsserver/dd448615.aspx
Is it different from any other certificate I can generate via makecert or buy from some authority?
As mentioned by Mile L and Boot to the Head the Extended Key Usage is what determines the purpose that the key can be used for.
Most commercial certificate authorities (Verisign et al) issue certificates for single purposes, or for as few as possible.
They use this narrowing of the puropse to carve out different markets for the certificates and then price them accordingly.
You see them selling different Object Signing certs for Windows Assemblies / Java / Office / Adobe Air etc when (in most cases) the resulting certificate is the same.
For example the Comodo codesigning cert issued here can sign Java applets, WebStart applications, Firefox extensions and even Windows assemblies.
The certificate that's used to sign software is the same certificate that would be used to sign any document. What's different about signing software is where the signature finally resides. In a typical document signing, the signature just gets appended to the original document. You cannot append a signature to most types of software for obvious reasons (some interpreted languages would allow this, but I don't know if it's done in practice).
The solutions to the signature problem vary based on the execution environment. For an executable binary, the signature is often stored in a separate file. In Java you can have a signature embedded in an executable JAR file.
Microsoft has a good reference for an introduction to the signing process.
It depends on what you are doing with it. If you want the certificate to be accepted by a browser in an SSL communication, then it must have a root certificate installed in the browser. The certificates generated by authorities already have their root certs installed in browsers.
If you are using the cert just to sign an assembly, then you don't need it. It depends on who is checking the cert and whether they care if the root is a known authority.
More here:
http://en.wikipedia.org/wiki/Root_certificate
To my knowledge, certificates have a "key usage" attribute that describes what uses the cert is intended for: SSL server, code signing, e-mail signing, etc. So I think it's up to the OS, or web browser, or e-mail client, to check these bits.
When a cert is called into action, the role it purports to perform is as important as identification. It's not just about identity, but also about role authorization. An email protection cert should not be able to perform server authentication. Security concerns dictate a necessary restriction in the power given through a single certificate. The underlying API should enforce the correct usage, be it through the OS or an abstraction such as the .NET Framework.
There are different certificate types because there are very different roles in authentication and authorization that would need them. Allowing different certificate types and hierarchies allow for a model of certificate chains, as found in the "Certification Path" on a certificate. A Server Authentication cert will need to have a top-level CA cert somewhere in the trusted root certificates... or be a part of a family tree of certs which ultimately does. 3rd party Certificate Authorities, I'm sure, price them on a scale of functionality and trust.
Boot To The Head is right... there is an Enhanced Key Usage attribute which provides a description of what the cert claims the role to be (e.g. Server Authentication; or in the case of my CA's cert: Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing). Look at the details in a certificate's properties and you'll find it.
I'd also add that a .NET assembly has to be strongly named (which requires it to be signed) in order to be added to the GAC.
There are different types of certs... from the CA that is bundled in Win 2003 server, you can request:
Client authentication
Email protection
Server authentication
Code signing
Time stamp signing
IPSec
Other