(Migrated) Certificate Authority and manual certificate creation

(This message has been automatically imported from the retired mailing list)

Hi,

I have a copule of questions about zato component certificates.

The quickstart command creates a simple CA which the docs recommend not
to use in a Production environment.

My question is: which is the alternative to using this CA?

And another question:
The docs show how to create a new component (f.e. a server) passing it
the pem certificates to be used.

The such certificates are created and this command executed “behind the
scenes” when the quickstart command is used, but I couldn’t make clear
how to perform these steps manually.

So the second question is:
Which is the recommended way to manually create the pem certificates?
And once they are created, how can them be inserted into the “trusted
wheel”. I mean: should they be imported in the CA, or signed by it, etc?

Kind regards,
Carles

On 05/23/2014 11:22 AM, Coeuz wrote:

Hi Carles,

The quickstart command creates a simple CA which the docs recommend not
to use in a Production environment.

Yes, this is a simple CA and currently there’s no plan to develop it
further. It serves its purpose of being available by default very nicely
but right now there are no plans to extend its functionality.

My question is: which is the alternative to using this CA?

And another question:
The docs show how to create a new component (f.e. a server) passing it
the pem certificates to be used.

The such certificates are created and this command executed “behind the
scenes” when the quickstart command is used, but I couldn’t make clear
how to perform these steps manually.

If you don’t have a CA in your organization and you’re not buying
certificates from commercial vendors, TinyCA2 is a nice package that
wraps openssl in a GUI that is very convenient to use.

So the second question is:
Which is the recommended way to manually create the pem certificates?
And once they are created, how can them be inserted into the “trusted
wheel”. I mean: should they be imported in the CA, or signed by it, etc?

Please go through the article linked above and I think it will clear out
the concepts behind running a CA.

Technically speaking, you are not required to have your own CA - you can
just buy certificates - but most organizations will have their own
internal CAs in any case so it may be possible that you need one as well.

Please let me know if this article helps or if you perhaps have
questions how to apply it to a Zato environment.

On 05/23/2014 11:22 AM, Coeuz wrote:

Hi Carles,

The quickstart command creates a simple CA which the docs recommend not
to use in a Production environment.

Yes, this is a simple CA and currently there’s no plan to develop it
further. It serves its purpose of being available by default very nicely
but right now there are no plans to extend its functionality.

My question is: which is the alternative to using this CA?

And another question:
The docs show how to create a new component (f.e. a server) passing it
the pem certificates to be used.

The such certificates are created and this command executed “behind the
scenes” when the quickstart command is used, but I couldn’t make clear
how to perform these steps manually.

If you don’t have a CA in your organization and you’re not buying
certificates from commercial vendors, TinyCA2 is a nice package that
wraps openssl in a GUI that is very convenient to use.

So the second question is:
Which is the recommended way to manually create the pem certificates?
And once they are created, how can them be inserted into the “trusted
wheel”. I mean: should they be imported in the CA, or signed by it, etc?

Please go through the article linked above and I think it will clear out
the concepts behind running a CA.

Technically speaking, you are not required to have your own CA - you can
just buy certificates - but most organizations will have their own
internal CAs in any case so it may be possible that you need one as well.

Please let me know if this article helps or if you perhaps have
questions how to apply it to a Zato environment.

On 05/23/2014 12:38 PM, Dariusz Suchojad wrote:

I just find it always most convenient to encrypt everything and not have
to worry about what exactly a trusted network is.

Let me just add to it a bit.

Intrusion detection isn’t something I specialize in so I can offer only
anecdotal evidence but over years I witnessed several break-ins. None of
them had anything to do with Zato, accidentally.

One, more than 10 years ago was a case of an unpatched Debian (Potato I
think) who external attackers took control of and eventually defaced the
web site this system was hosting. Unpatched system, external attackers,
web site changed

But the remaining 4-5 were always performed by insiders. These were
people who knew these systems from the inside, knew how to game them and
took advantage of it in various ways.

All these attacks took place in trusted networks - which basically meant
private ones - in rather large organizations, with a couple of thousand
people working in IT alone.

These are my observations and though I admittedly don’t precisely know
how closely it resembles everyone else’s experience, this is part of
what influences Zato’s design.

Now, naturally everything is a matter of costs. I can easily understand
that there are situations when costs of setting up and maintaining CAs
and certificates outweigh the costs of cleaning up a potential break-in.

Thus if you could please open a GH ticket regarding that matter, I can
see what can be done in order to have clusters with no certificates at all.

thanks a lot,