So at the company I work for, most of the internal systems have
expired SSL certs, or self-signed certs. Obviously this is bad.
I know that if we had IT put our root cert in the browsers, that we
could then generate our own SSL certs.
Are there any options that don't involve adding a new root CA
>Are there any options that don't involve adding a new root CA?
Assuming your sites all use subdomains of your company domain,
a wildcard cert for *.whatever might do the trick. It's relatively
expensive, but you can use the same cert in all your servers.
>I would think this would be rather comm
[EMAIL PROTECTED] wrote:
So at the company I work for, most of the internal systems have
expired SSL certs, or self-signed certs. Obviously this is bad.
Sorta. TLS gets along with self signed just fine though, and obviously
you can choose to accept a root or unsigned cert on a per-client basi
[EMAIL PROTECTED] writes:
>I would think this would be rather common, and I may have heard about certs
>that had authority to sign other certs in some circumstances...
The desire to do it isn't uncommon, but it runs into problems with PKI
religious dogma that only a CA can ever issue a certificat
[EMAIL PROTECTED] wrote:
So at the company I work for, most of the internal systems have
expired SSL certs, or self-signed certs. Obviously this is bad.
You only think this is bad because you believe CAs add some value.
SSH keys aren't signed and don't expire. Is that bad?
--
http://www.apac
>> So at the company I work for, most of the internal systems have
>> expired SSL certs, or self-signed certs. Obviously this is bad.
>
>You only think this is bad because you believe CAs add some value.
Presumably the value they add is that they keep browsers from popping
up scary warning messag
On Mar 16, 2008, at 12:32 PM, Ben Laurie wrote:
[EMAIL PROTECTED] wrote:
So at the company I work for, most of the internal systems have
expired SSL certs, or self-signed certs. Obviously this is bad.
You only think this is bad because you believe CAs add some value.
SSH keys aren't signed
| >> So at the company I work for, most of the internal systems have
| >> expired SSL certs, or self-signed certs. Obviously this is bad.
| >
| >You only think this is bad because you believe CAs add some value.
|
| Presumably the value they add is that they keep browsers from popping
| up scary
On Mar 17, 2008, at 10:06 AM, Leichter, Jerry wrote:
| >> So at the company I work for, most of the internal systems have
| >> expired SSL certs, or self-signed certs. Obviously this is bad.
| >
| >You only think this is bad because you believe CAs add some value.
|
| Presumably the value they
>| Presumably the value they add is that they keep browsers from popping
>| up scary warning messages
>Apple's Mail.app checks certs on SSL-based mail server connections.
>It has the good - but also bad - feature that it *always* asks for
>user approval if it gets a cert it doesn't like.
Good
On Mar 16, 2008, at 8:50 AM, John Levine wrote:
So at the company I work for, most of the internal systems have
expired SSL certs, or self-signed certs. Obviously this is bad.
You only think this is bad because you believe CAs add some value.
Presumably the value they add is that they keep
[EMAIL PROTECTED] (Peter Gutmann) on Sunday, March 16, 2008 wrote:
>[EMAIL PROTECTED] writes:
>
>>I would think this would be rather common, and I may have heard about certs
>>that had authority to sign other certs in some circumstances...
>
>The desire to do it isn't uncommon, but it runs into pr
John Levine wrote:
| Presumably the value they add is that they keep browsers from popping
| up scary warning messages
Apple's Mail.app checks certs on SSL-based mail server connections.
It has the good - but also bad - feature that it *always* asks for
user approval if it gets a cert it does
Dirk-Willem van Gulik wrote:
So I'd argue that while x509, its CA's and its CRL's are a serious pain
to deal** with, and seem add little value if you assume avery diligent
and experienced operational team -- they do provide a useful
'procedural' framework and workflow-guide which is in itself v
On Mar 16, 2008, at 7:52 PM, Ben Laurie wrote:
Dirk-Willem van Gulik wrote:
So I'd argue that while x509, its CA's and its CRL's are a serious
pain to deal** with, and seem add little value if you assume avery
diligent and experienced operational team -- they do provide a
useful 'procedur
15 matches
Mail list logo
