Server certificate renewal

[Stefan Winter]

Hi,

> Trusting a certificate manually is a good thing dont you think? In this way aware clients can be ware of the fact that the server to which they are supplying there credentials is really the "correct" server by looking at the chain, and is not a dummy server which will steal there credentials.

It's a halfways good idea.

It's better then trusting "everything" by just clicking OK to every
warning message the user sees.

Trusting the (one) certificate is acceptable if the user ACTUALLY
COMPARES the fingerprint in the warning message to documentation from
the operator. Only then can the user be sure to connect to the right
server. (Honestly: do you think users actually check the presented
fingerprint values???)

But even if done right, this one-certificate-trust is still inferior to
an actual CA chain verification: exactly as is happening in this thread
- the cert will eventually expire, get replaced, and then the trust is
broken and needs to be re-established.

The better way of configuring this is by using a (very long-lived, i.e.
20 years or more) private CA which issues the server certificates and to
install that CA as trust root in the end user devices.

That way, you can renew certificates from the same CA, and since the CA
is the trust anchor, it does not change. Devices honour that and do not
generate a warning during certificate rollover.

A good way to get CA certificates onto the device in a streamlined
manner is https://802.1x-config.org or, for eduroam identity providers,
https://cat.eduroam.org.

Greetings,

Stefan Winter

> 
> BR,
> Anirudh Malhotra
> 8zero2
> Mail: 8zero2.in at gmail.com
> Facebook: www.facebook.com/8zero2
> Twitter: @8zero2_in
> Blog: blog.8zero2.in
> 
> On 10 Jan 2016, 20:53 +0530, Alan DeKok<aland at deployingradius.com>, wrote:
>> On Jan 10, 2016, at 6:25 AM, douglas eseng<douglas.eseng at gmail.com>wrote:
>>> After renewal of server cert, existing iOS devices ask user to again trust
>>> the cert. Is this normal behaviour?
>>
>> Yes.
>>
>>> Since it was a renewal, would have
>>> thought it is recognized as the same cert and remain trusted.
>>
>> What, exactly, makes it the "same" cert? The private key has changed. The public key has changed. The fingerprint has changed. The expiry date has changed.
>>
>> Some fields in the new cert are the same as the old one, so that might help. But there's nothing in the new cert which says "this certificate replaced old certificate X".
>>
>>> Anyone know once user trusted the cert, what digest/fingerprint of the cert
>>> does IOS remember? Unable to find info on this from Apple's site.
>>
>> iOS remembers the fingerprint. Which has changed.
>>
>> Every time you add a cert, you've got to trust it again. There is a chain of trust for signing certificates. There is no chain of trust for replacing certificates.
>>
>> Alan DeKok.
>>
>>
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> 


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20160111/b2ed1301/attachment.sig>