J'ai ajouté un certificat SSL (de Godaddy, mais a également essayé Rapidsssl) sur un site Web.
Safari, et c'est-à-dire que celles-ci peuvent naviguer vers https: // et signaler que le certificat est valide, sans avertissements. Si, cependant, j'essaie de parcourir la même adresse d'un iPhone, je reçois une erreur de certificat invalide. J'utilise Heroku comme hôte pour le site Web en question.
Quelqu'un a-t-il vu ceci? Je suis enlevé pourquoi 2 iphones différents ne manqueraient pas de le faire, mais les navigateurs de bureau sont très bien ...
4 Réponses :
Tout simplement parce que ces deux autorités de certification ne sont pas dans le magasin de certificats de confiance de l'iPhone, mais ils sont pour Windows, Firefox, etc.
EDIT:
Je suppose que l'affiche précédente est correcte, vous n'êtes pas regroupé les certs intermédiaires. Votre certificat peut avoir été signé par RapidsssL.com, mais le certificat de Rapidssl.com a été signé par Equifax. Chaque certificat a un champ de nom d'émetteur et un champ de nom de sujet; Pensez à ceux-ci comme une paire de noms (x, y). Le nom du sujet de votre certificat reflète le nom de votre site Web, et il a été signé par RapidssSL, de sorte que la paire est quelque chose comme (Rapidssl, www.whatever.com). Le CERT RAPIDSSL a été signé par EQUIFAX, de sorte que cela rendrait la paire (Equifax, Rapidssl). Et le certificat Equifax pourrait avoir (Equifax, Equifax). Le cert root doit avoir le même émetteur et le même nom de sujet. Comme vous pouvez le constater, cela forme une chaîne de la forme (A, A) (A, B) (B, C) (C, D) .... Pour cependant, cela va. Il est rarement plus long que 3. La règle de SSL est que vous devez envoyer chaque certificat dans la chaîne sauf le certificat racine. Certains clients peuvent déjà avoir le ou les certs intermédiaires, mais vous ne devriez jamais compter sur cela.
Les deux fournisseurs sont dans le magasin de certificats, selon Apple: support.apple.com/kb/ht3580
À quoi ressemble la chaîne de certificats jusqu'à votre certificat? Je suis intéressé par l'émetteur et le sujet DNS, qui n'incluait pas le sujet DN de votre certificat.
La chaîne est fondamentalement «autorité de certification sécurisée Equifax», dans laquelle j'ai mon propre certificat pour le domaine. Je ne suis pas sûr de ce que vous entendez par «DNS soumis»?
Désolé d'utiliser Jargon. DN est court pour "Nom distinctif". Fondamentalement, chaque certificat a un champ pour le nom de l'émetteur et un autre domaine pour le nom de sujet.
Hmmm, je ne vois pas le Rapidsssl ca sur ce lien Apple.com
Vous devez également faire référence au certificat intermédiaire afin que vous ayez l'ensemble de la chaîne de certificats au certificat racine.
voir Ce blog post pour une description du même problème et de la façon dont il l'a résolu pour Apache.
Je l'ai fait pour le Godaddy Cert - vous venez de chat ensemble le paquet avec votre certificat. Notez que j'ai dit que cela fonctionne très bien sur tous les navigateurs que j'ai essayés, tout simplement pas l'iPhone, alors sûr que le certificat est installé correctement.
J'ai eu ce même problème (avec un BlackBerry ainsi que l'iPhone). C'était exactement ça. Le serveur n'envoie que le certificat et attendez-vous que le client ait le cert intermédiaire ainsi que le certificat racine. Périphériques mobiles Plusieurs fois n'ont pas ces certificats intermédiaires installés, de sorte que la chaîne de confiance est cassée.
À titre d'exemple, mon firefox 3.5.6 a un certificat intermédiaire Go Go Daddy mais pas le certificat intermédiaire Rapidsssl.
Le problème ici s'est avéré que l'iPhone ne prend pas en charge l'indication du nom du serveur (SNI), qui est nécessaire pour rendre SNI SSL de Heroku au travail. (Modifier) Il est maintenant pris en charge sur iOS 3.2.
Vous pouvez confirmer SNI en allant à l'URL suivante de Safari sur le téléphone:
J'ai compris que je peux définir le paramètre SSL suivant dans le client iPhone:
kcfstreamssslpeername = null
... et cela corrige le problème. Mais je n'ai pas encore compris comment cela affecte la sécurité - les docs ne sont pas très clairs.
Autant que je comprends cela, lorsque vous configurez un domaine personnalisé sur un hôte cloud tel que Heroku, il pointe vers un proxy et ce nom ne correspond pas à votre nom d'hôte de certificat. Des navigateurs tels que Safari et IE Support Sni, et savent comment comprendre cette sortie - mais le téléphone ne le fait pas.
Comme je l'ai dit ci-dessus, il s'agit moins d'un problème, à moins que vous soyez à la charge de l'IOS 3.1.3 ou moins ...
Merci pour le lien pratique. FYI vient de l'essayer sur iPhone basé sur iOS4 et est pris en charge dans iOS4. Je n'ai pas essayé les versions précédentes.
Je pense que le support SNI n'est pas là sur l'iPad - 3.2.2 vient de l'essayer maintenant. Cela fonctionne sur un iPhone 4.1 et il devrait également fonctionner sur iPad 4.2, semble-t-il. Ceci est sur un site Sni Heroku qui fonctionne partout ailleurs, cept XP (XP ne prend pas en charge SNI)
Je sais que cela a été répondu, mais au cas où n'importe qui apparaît à nouveau sur ce problème, je pensais que je partageais ce que j'ai manqué depuis que je suis récemment passé par le même mal de tête, mais j'ai une architecture légèrement différente.
Notre configuration du serveur était un peu différente en ce que nous avions un trafic SSL scintillement, ce qui le transmettait à Haproxy qui l'acheminerait à Apache qui le procurerait à nos serveurs d'applications. Après avoir joué avec Apache pendant un moment, j'ai réalisé que la configuration Stunnel n'inclut pas les certificats intermédiaires, donc j'ai concatéré le certificat de domaine (premier), puis les certificats intermédiaires (pour faire une grande longue chaîne de certificats).
qui a corrigé le problème pour moi.
Je pense que ServerFault pourrait être un meilleur endroit pour cela.