Aller au contenu

pitch78

Membres
  • Compteur de contenus

    51
  • Inscription

  • Dernière visite

Messages posté(e)s par pitch78

  1. Il y a 3 heures, 2.hd a dit :

    Bonjour et un grand merci pour le suivi et les mises à jour.

    De mon coté, si le fichier se télécharge bien avec la version 4.1 du fichier host, il semble que Download Station n'arrive pas à récupérer le nom originel du fichier, et me crée donc un fichier avec un nom du style "0zbhp3gzvgckeifmp5mi".

    Après recherche sur le web, il semblerait que cela pourrait être lié à l'option "Forcer l'affichage du menu pour les téléchargements" dans les paramètres du compte 1fichier, mais je confirme que c'est bien décoché. Par ailleurs, quand  je lance le téléchargement via Chrome, celui-ci récupère bien le nom originel.

    Auriez vous des conseils ou recommandations?

    Merci d'avance 😉 

    Que donne le log "Réponse brute de l'api à https://api.1fichier.com/v1/file/info.cgi"?

  2. Il y a 20 heures, Mathieu Vedie a dit :

    Nouvelle version : 4.1.0 (lien dans le premier poste)

    Plutot que d'utiliser la methode d'API permettant d'accèder aux infos du compte, j'essaye simplement d'acceder aux informations d'un fichier que j'ai uploadé et que je vais laisser à demeure. ça evite les blocages juste pour valider l'apikey dans l'interface. 

    👌🏻

  3. En gros, l'url appelée pour faire la vérification est très (beaucoup trop) sensible et peut déclencher un status de flood (trop de rêquetes, donc suspect) sur le compte après 2/3 appels, voir même un seul appel...
    Et cela peut aller jusqu'au blocage (temporaire) de l'IP si l'on continue.
    A noter qu'avant c'est le site de 1fichier lui-même qui était analysé pour déterminer le type de compte, cette fonction était donc utile pour confirmer que le status free / premium était bien identifié.
    Maintenant que le fichier host passe par l'API de 1fichier, cette vérification n'a plus de sens / intérêt car les membres utilisant cette version sont forcément premium, sinon ils n'auraient pas accès à l'API.
    Après, c'est en place car je suppose que c'est une contrainte pour le fichier host, que d'avoir cette fonction.
    Les urls de téléchargement se comportent elles "normalement" et devrait fonctionner à condition que le compte ne soit pas bloqué (temporairement) par notamment des appels à l'url de vérification.
    En gros si vous avez votre clé API, mettez la bien dans le champ password et ne faites pas de vérification.
    Et si cela ne fonctionne pas alors activez les logs.

  4. Ok, bon c'est pas grave.
    Le truc c'est que pour l'instant le script fait tout ce qui est nécessaire quand tout va bien et honnêtement, vue la simplicité (c'est un compliment) je pensais pas qu'il y ait vraiment besoin de plus.
    @Faucon Noir, S'il n'y a pas de log car le script n'écrit rien, pas de texte, de logs,...

    Le plus simple serait soit d'éxécuter une requête depuis postman ou un équivalent, ou si vous savez utiliser la ligne de commande. un curl ou un wget, genre:
     

    curl --location 'https://api.1fichier.com/v1/file/info.cgi' --header 'Content-Type: application/json' --header 'Authorization: Bearer votre_token_ici' --data '{ "url": "url_1fichier__de_test_ici"}'

    en remplaçant évidemment votre_token_ici par votre clé API 1fichier et url_1fichier__de_test_ici par une vrai url de type https://1fichier.com/?XYZ

    Attention, pour ces requêtes faites "main" pensez bien à enlever la partie affiliation: &af=1324567

    sinon, cela ne fonctionne pas.
    et vous aurez une réponse du genre:
     

    {
    "message": "Resource not found #520",
    "status": "KO"
    }
     

    Dans le script, il le fait pour vous.

    Vous pouvez aussi essayé l'autre url "utile" et mettre https://api.1fichier.com/v1/download/get_token.cgi à la place de https://api.1fichier.com/v1/file/info.cgi dans la commande ci-dessous

    le résultat donnera alors peut-être plus de précision sur la nature de vos erreurs
    🤞🏻

  5. @baobab379 et @Holborn A,
    avez-vous essayé directement de lancer un téléchargement, sans faire la vérification de compte?
    Avec la version 4.0.X, la vérification de compte ne sert plus vraiment utile (peut-être si / quand le cdn sera remis, je ne sais pas)
    Si vous avez un clé API, c'est que vous êtes premium.
    Le problème que j'ai rencontré, comme d'autre d'ailleurs est que le test du type de compte ne semble pas très stable.
    Du coup, vous faites un test, ça fonctionne (ou pas d'ailleurs) et derrière votre user est banni.
    Du coup, quand vous lancer un téléchargement votre user n'est pas "valide" et si vous insistez, c'est votre IP qui est bannie.
    Pas de panique, ça revient après un moment (je ne sais pas combien, mais < 1h)

  6. il y a 39 minutes, Mathieu Vedie a dit :

    J'ai justement beaucoup galéré pour dev cette version basé sur l'API car j'etait confronté au même problème que toi, puis j'ai fini par me rendre compte que la route  'https://api.1fichier.com/v1/user/info.cgi' entrainait beaucoup plus de blocage que les routes pour acceders au informations des fichiers et des liens, respectivement 'https://api.1fichier.com/v1/file/info.cgi' et 'https://api.1fichier.com/v1/download/get_token.cgi'

    C'est effectivement surement ce qui explique ce que j'ai observé.
    Pour l'histoire des 100Mio/s, je vais continué de faire des tests croisés entre mon ordi et mes NAS pour voir...
    Mais en tout cas, j'ai pu lancer qq téléchargement de tests, ça fonctionne.
    Sinon, j'ai regardé l'API et... ben t'as tout fait, pour moi y'a rien besoin de plus dans ton script.
    Tout est là et c'est vraiment plus simple / clair / lisible que la version qui parsait les pages web 😅
    Un grand merci.
     

  7. Bonjour,
    déjà merci pour le travail,
    chez moi ça commencé à bloquer depuis hier, et j'ai remarqué que le script 3.2.5 récupérait une page (https://1fichier.com/console/index.pl) complète et cherchait entre autres variations "Compte offre Premium"
    hors, j'ai maintenant "Compte Premium" donc forcément, ça trouve pas.
    j'allais me faire un script qd j'ai vu qu'une version 4, basée sur l'API (c'est toujours plus simple normalement) avait été faite. (du coup j'ai pas regardeé les versions intermédiaires)
    sauf que là, c'est un peu la cata.

    Connaissez vous les limitations de l'API 1fichier (nb requetes max sur une période donnée)
    Je m'explique:

    • J'ai installer le host 4.0.0
    • J'ai fait "vérifier", ça a fonctionné. Parfait.
    • J'ai lancé un téléchargement, ça a échoué. Comme je ne voulais pas redémarrer mon NAS, j'ai juste stoppé le package dlStation, puis je l'ai relancé, j'ai essayé un autre téléchargement, j'ai reçu un fichier dont le nom était celui du lien et qui c'est avéré être la page html de dl de 1fichier demandant de se logger.
    • j'ai retesté le compte, avec le bouton de vérification => échec
    • comme c'est pas très précis, j'ai essayé un POST https://api.1fichier.com/v1/user/info.cgi dans postman
    • ça m'a répondu KO, Flood detected, user blocked (oups)
    • j'ai attendu un peu, genre > 1m
    • j'ai relancé la requete ça m'a répondu OK, avec tous les détails (cool)
    • j'ai attendu un peu, genre > 30s et relancé
    • ça m'a répondu
      {
      "message": "Flood detected: IP Locked #41",
      "status": "KO"
      }
    • re oups
    • ensuite j'ai écrit tout ce message et re-testé depuis postman et ça refonctionne (en tout cas au moins ce endpoint de vérif)

    Du coup, là c'est un peu pénible, mais c'est surtout pour la suite, car là j'ai littéralement fait 4/5 requêtes en tout.
    Il va se passer quoi si j'ajoute 10 liens d'un coup, je suis ban pour un mois 😅

    Du coup je suis preneur de vos retours: suis-je le seul, connaissez vous les limites,...
    Merci.

    A et dernière chose (que je viens de constater en faisant qq essais) est-ce bien la même url finale qu'avant qui est utilisée?
    Bizarrement, le téléchargement semble bloqué à ~100Mo/s. jusqu'à hier j'ai la majorité du temps à ~350Mo/s sur mon NAS et sur mon PC, qui n'est "que" en 2.5Gbits/s le même lien (lancé juste avant ou juste après) part directement à ~200Mo/s

  8. Bon un petit post pour essayer de comprendre.

    Il y a peut-être déjà tout (désolé si c'est le cas) mais j'ai pas trouvé.

    ce que je veux :

    • me connecter en ssh, par clé publique et non pas par mot de passe. je le fais déjà sur un autre NAS (1511+) et sur plusieurs raspberry.

    La situation :

    • un nouveau NAS (1817+)
    • mêmes clés publiques (puisque je me connecte depuis les mêmes machines)
    • .ssh créé dans le ~/.ssh de l'utilisateur
    • /etc/ssh/sshd_config configuré "correctement"
    • ~/.ssh en 700
    • ~/.ssh/authorized_keys en 600

    Le problème :

    • lorsque je tente de me connecté via ssh (linux, osx) il me demande le mot de passe
    • lorsque je tente depuis avec putty (il est plus explicite) il me dit Server refused our key, puis demande un mot de passe

    Ce que j'ai vu et fait pour que ça marche :

    • les droits du répertoire ~ de l'utilisateur sont : drwxrwxrwx+
    • ne connaissant pas cette notation j'ai fait un chmod 700
    • ça a fonctionné

    Ce qu'il faut faire pour revenir à cette situation :

    • aller dans homes sur filestation
    • clic droit / propriétés sur le home de l'utilisateur concerné
    • Onglet permission
    • cliquer sur options avancées / inclures les permissions héritées
    • les droits de ~ repassent à drwxrwxrwx+ et l'accès est à nouveau refusé

    Du coup je me doute bien que c'est un problème de droit, mais j'avoue ne pas vraiment comprendre ou s'applique la restriction / quelle en est l'origine

    Mes questions :

    • quelle est la restriction qui joue ici
    • que signifie drwxrwxrwx+
    • mon action est-elle "dangereuse" et si oui comment concilier une configuration sécurisée comme à l'origine et un accès ssh par clé publique.

    D'avance merci pour vos lumières !

     

     

     

     

     

  9. Il y a 1 heure, Einsteinium a dit :

    Je suis en adsl free et aucun soucis d'accès pour ma part, même faire une recherche de maj ne retourne pas d’erreur.

    pour moi aussi la recherche de mise à jour me dit que je suis à jour, sans aucune erreur retournée (même sur mon nouveau NAS).

    et au boulot (adsl orange) ça semblait fonctionner, mise à jour de package OK, mais impossible par exemple d'installer MariaDB 10 pour pouvoir mettre à jour phpmyadmin ou mediawiki.

    chez moi, j'ai reçu mon nouveau NAS vendredi du coup il n'a jamais pu lister de paquets et c'est toujours impossible.

    c'est pas franc franc comme problème :confused:

    en espérant que ça se résolve rapidement "tout seul" avec la propagation des DNS et BGP...

  10. il y a 26 minutes, loops a dit :

    Oui c'est ça le plus étrange !!

    J'ai accès sur un autre NAS chez un copain et chez lui pas de problème.

    Je m'arrache un peu les cheveux pour trouver la cause. Le modèle, le FAI, le DNS, le routage, ...

    Chez moi (ADSL Free),

    sur le nouveau NAS rien.

    sur l'ancien, il affiche la liste mais c'est tout...

     

    Au boulot (ADSL Orange),

    sur un NAS rien, impossible de lister des paquets,

    sur l'autre des mises à jours étaient dispo et j'ai pu les faire, sauf phpmyadmin & mediawiki qui nécessitaient MariDB 10, qui n'était pas listé dans les paquets "connus" et pour le coup, impossible de mettre à jour le listing des paquets pour avoir maria DB 10 et donc faire les mises à jours.

    MariaDB 5 lui par contre a bien pu être mis à jour...

    Impossible aussi d'avoir les paquets de synocommunity (mais attention, ça n'a peut-être/surement) rien à voir, je ne sais pas...

    bref, wait & see

     

  11. Il y a 2 heures, lordtaki a dit :

    J'ai déjà eu ces symptômes lors de la sortie récente de nouvelles versions de paquets.

    Je pars du principe que les serveurs de Syno sont saturés rapidement par les utilisateurs qui se dépêchent de faire la mise à jour.

    dommage que les serveurs ne tiennent pas le choc, j'ai reçu aujourd'hui un nouveau nas pour relayer l'actuel un peu à la peine et du coup ça coince...

    enfin pas grave il fait beau, c'est pas comme si on était en mode tanière en plein hiver...

  12. Bonjour,

    j'ai configuré webdav pour échanger facilement des petits fichiers.

    Sauf que je peux récupérer des fichiers depuis chez moi, en envoyer

    MAIS il m'est impossible de renommer les fichiers ou répertoire à distance. Je peux par exemple aussi créer un répertoire, mais pas lui donner un nom, il se nommera donc forcement "Nouveau dossier" :confused:

    une idée ?

    d'avance merci !

  13. Bon trouvé...

    J'ai pas mal joué avec la config nginx et notamment pour augmenter la sécurité (dhparam,...)

    toujours est-il que dans le fichier proxy_default.conf, le paramètre

    Citation
    
    proxy_http_version 1.1;
    

    était commenté, suite à une modification ou par erreur je ne saurais pas le dire, toujours est-il que

    • avec le paramètre actif entry.cgi  avec les arguments api=SYNO.Core.Desktop.Initdata&method=get&version=1 semble lu depuis un cache local et la page complète pèse environ 300ko,
    • sans, entry.cgi avec ces mêmes paramètres est entièrement retéléchargé chaque fois et le site pèse environ 1,3Mo, d'ou un temps de chargement à +10 secondes.

    Attention donc... en espérant que ça en aide d'autre,

    Bonne journée !

     

  14. Le 27/04/2017 à 15:43, Fenrir a dit :

    Tu peux aussi faire ta demande en plusieurs fois (tu peux avoir plusieurs certificats).

    oui, mais ça m’embêtais un peu, surtout vis à vis du renouvellement. avoir un seul certificat voulais dire un seul renouvellement et donc ouvrir une seule fois le port 80 (d'ailleurs, peut-on scripter "proprement" cette ouverture ? je pense sinon analyser les logs de lets encrypt pour détecter une demande de renouvellement...).

    Par rapport au reverse proxy, encore un problème :

    à l'extérieur de chez moi, DSM met plus de 10 secondes à s'afficher. Pas chez moi, alors que j'utilise la même URL. ET pas non plus à l'extérieur si je n'utilise pas la config reverse proxy, juste du port forwarding.

    Après quelques recherches, j'ai isolé le problème :

    un accès à entry.cgi (je sais il y en a à foison)  avec les arguments api=SYNO.Core.Desktop.Initdata&method=get&version=1

    hors le json retourné fait quasiment 1Mo (d'ou les 10s avec une connexion ADSL à 100ko/s en up).

    pour le reste du chargement de la page c'est peut-être pareil, mais comme c'est plus petit, c'est moins quantifiable.

    c'est comme si, avec le reverse proxy j’empêchais d'utiliser le cache ?

    Avez vous déjà été confronté à ça ?

    D'avance merci

  15. Bonjour,

    petit retour concernant mes questions précédentes.

    Merci, car j'ai découvert grâce à vous les certificats multi domaines avec le champ SAN. Je pensais avant que seul l'utilisation de certificats wildcard pouvait gérer plus de 1 domaine.

    j'ai pu grâce à celà utiliser un certificat let's encrypt pour une vingtaine de domaine.

    un préfixe de domaine = un service pour chez moi, d'ou le nombre, car je me développe plein de petits services tout con mais très pratiques.

    Petite information, vu le nombre de domaines que j'avais, je pouvais soit utiliser le client en ligne de commande, mais j'ai pas trouvé dans celui intégré à DSM comment bien gérer le champ SAN,

    soit utiliser l'IHM de DSM qui présentait l'avantage de gérer seul le renouvellement du certificat, sauf que ma liste était trop longue :cry:

    je me pensais foutu, et puis j'ai tenté... et ça à marché !

    il suffit en effet de supprimer l'attribut maxlength du champ html INPUT de "Autres nom de l'objet" qui est par defaut à 256 caractères max et ça passe

    pour ceux qui ne savent pas faire, utilisez l'inspecteur de votre navigateur, selectionnez le champ html et editez ou supprimez l'attribut maxlength

    si ça peux aider... 

  16. et il se passe quoi si j'utilise pas propre autorité (d'ailleurs est-ce un certificat auto-signé ou autre chose ?), sans l'installer sur tous les clients ?

    1) c'est crypté, mais pas authentifié (pas d'adresse en vert) ?

    2) c'est inaccessible ? comme actuellement ou chrome m'empêche totalement l'accès à mes services

    3) c'est dangereux dans le sens ou ça peut être usurpé ?

    car sans wildcard, l'interet du reverse proxy que je faisais par sous-domaines est plus que discutable dans mon cas.

    sinon des redirection par ports feraient le boulot ou par url genre

    https://mondomaine.fr/service au lieu de https://service.mondomaine.fr

    moi ce qui m’intéresse c'est que le traffic, notamment mot de passe,... ne passe pas en clair... 

    c'est la lose, là toute mon organisation tombe à l'eau :cry:

     

  17. Bonjour,

    j'utilise le reverse proxy de CoolRaoul depuis la mise en place nginx.

    je l'avais fait seul sous apache avant, mais ne connaissant pas nginx, ce tuto m'avais été d'un grand secours.

    je dirais même que je ne l'aurais pas fait sans ce tuto !

    Mais depuis la semaine dernière j'ai un "très" gros problème, dont je ne soupçonnais pas l'existance, mon certificat est un certif... starcom :confused:

    j'ai vu dans ce post que ça traine depuis plusieurs mois et que c'est connu,

    mais il y a quelques mois (l'année dernière, même époque ?), quand le sha1 avait été proscrit, les navigateurs (chrome pour moi) le signalait avec un symbol particulier dans la barre l'url, mais pas cette fois-ci. je me suis donc fait surprendre lors de la mise à jour.

    du coup j'ai une dizaine de services auto hébergés (principalement de la domotique) auquel je n'ai plus du tout accès, n'ayant ouvert que le https sur le reverse proxy.

    du coup j'ai 3 solutions :

    1) ouvrir le http (j'ai vraiment vraiment pas envie)

    2) utiliser un autre fournisseur de certificat (j'utilise du wildcard, car j'ai un service == un sous domaine) et je sais pas trop vers lequel me tourner (prix/service/fiabilité) et surtout niveau prix, c'est juste impossible (genre 300$ / 400$ par an :eek:) c'est pour un usage perso.

    chez starcom, j'utilisais une validation d'identité (60$ pour un an) et les certificats étaient valables 2ans, donc en la jouant bien, ça faisait 60$ pour 3ans... et 2 certificats wildcard...

    3) utiliser lets encrypt, MAIS :

    -impossible d'avoir un certificat wildcard, ça risque d'être penible

    - nginx (le perso du reverse proxy) peut-il utiliser directement le certificat de DSM (qui il me semble gère l'auto renouvellement)

    - idem avec SRM, qui utilisait mon certificat, hors pas de lets encrypt (pour le moment ?) dessus

    car recopier ou renouveler un certificat tous les 2 / 3 ans ça va, mais tous les 30 ou 90 jours c'est lourd...

    d'avance merci pour vos conseils, car là je suis bloqué/dégouté...

     

     

  18. bon en fait tout con et si ça peut servir...

     

    je ne m'en souvenais plus et malgré le fait que je soit derriere un routeur, j'ai configuré mon port ssh local sur un port non standard.

    du coup j'ai la configuration de sftp en 22 et de ssh sur un autre port. je ne sais d'ailleurs pas pourquoi sftp à son propre port et qu'il n'utilise pas celui défini pour ssh ???

    du coup ça marchait avec winSCP, je ne sais pas pourquoi.

    ça ne marchait pas avec filezilla et mon editeur de texte, je ne sais pas pourquoi.

     

    MAIS en mettant les 2 sur le même port (cequi parait a priori logique) ça fonctionne partout...

    si ça peut servir à quelqu'un...

  19. Bonjour,

    je viens d'activer SFTP sur mon nas (1511+, DSM 6.0.2-8451 Update 7). le ssh fonctionne correctement via mot de passe et clé privée.

    le sftp fonctionne très bien avec WinSCP,

    mais impossible de l'utiliser avec un plugin (Sublime SFTP) de mon editeur de texte (sublime text): timeout. c'est le but final de l'activation du sftp pour moi)

    bon sur ce point c'est peut-être un peu trop particulier,

    mais avec filezilla j'ai un message : Received unexpected end-of-file from SFTP server.

    Je précise que l'authentification se passe bien, c'est après que ça déconne...

    j'ai essayé en mettant le répertoire distant à vide, puis en relatif (par rapport à mon home), puis en absolu. toujours le même message :sad:

    là je sais plus quoi regarder...

    d'avance merci si vous avez une idée

    Pour infos, le log "debug" de filezilla :

    Statut :	Déconnecté du serveur
    Statut :	Connexion à sftp.XXX:XXXXX...
    Suivi :	Going to execute C:\Program Files (x86)\FileZilla FTP Client\fzsftp.exe
    Réponse :	fzSftp started, protocol_version=7
    Suivi :	CSftpControlSocket::ConnectParseResponse(fzSftp started, protocol_version=7)
    Suivi :	CSftpControlSocket::SendNextCommand()
    Suivi :	CSftpControlSocket::ConnectSend()
    Commande :	keyfile "C:\Users\moi\Documents\X\cle_privee.ppk"
    Suivi :	CSftpControlSocket::ConnectParseResponse()
    Suivi :	CSftpControlSocket::SendNextCommand()
    Suivi :	CSftpControlSocket::ConnectSend()
    Commande :	open "moi@sftp.XXX" XXXXX
    Suivi :	Connecting to aaa.bbb.ccc.ddd port XXXXXX
    Suivi :	We claim version: SSH-2.0-PuTTY_Local:_Dec__6_2016_17:17:17
    Suivi :	Server version: SSH-2.0-OpenSSH_6.8p1-hpn14v6
    Suivi :	Using SSH protocol version 2
    Suivi :	Doing ECDH key exchange with curve Curve25519 and hash SHA-256
    Suivi :	Server also has ecdsa-sha2-nistp256/ssh-dss host keys, but we don't know any of them
    Suivi :	Host key fingerprint is:
    Suivi :	ssh-ed25519 256 -----------------------------------------------
    Suivi :	Initialised AES-256 GCM client->server encryption
    Suivi :	Initialised AES256 GCM client->server MAC algorithm (in ETM mode) (required by cipher)
    Suivi :	Initialised AES-256 GCM server->client encryption
    Suivi :	Initialised AES256 GCM server->client MAC algorithm (in ETM mode) (required by cipher)
    Suivi :	Successfully loaded 1 key pair from file
    Suivi :	Offered public key from "C:\Users\moi\Documents\X\cle_privee.ppk"
    Suivi :	Offer of public key accepted, trying to authenticate using it.
    Suivi :	Access granted
    Suivi :	Opening session as main channel
    Suivi :	Opened main channel
    Suivi :	Primary command failed; attempting fallback
    Suivi :	Started a shell/command
    Statut :	Connected to sftp.XXX
    Erreur :	Received unexpected end-of-file from SFTP server
    Suivi :	CSftpControlSocket::OnTerminate without error
    Suivi :	CSftpControlSocket::ResetOperation(66)
    Suivi :	CControlSocket::ResetOperation(66)
    Erreur :	Impossible d'établir une connexion au serveur
    

     

  20. :cool:    J'ai trouvé !

    le problème venait du certificat, j'ai généré ma demande en suivant bêtement les indications de StartSSL (cf capture ci-jointe).

    openssl req -newkey rsa:2048 -keyout macleprivee.key -out mademande.csr

    Hors je viens de remarquer que la clé privée précédente était plus longue.

    du coup je viens de recommencer avec

    openssl req -newkey rsa:4096 -keyout macleprivee.key -out mademande.csr

    puis j'ai décrypté ma clé, puis j'ai sélectionné :

    • ma clé
    • mon certificat
    • le certificat intermédiaire (issue de la configuration toute prête pour apache de l'archive StartSSL du certificat)

    et hop magie, ça passe.

    du coup je copie ça dans ma config reverseProxy et je vous confirme que tout marche, mais il n'y a pas de raison.

    en espérant que ça serve à d'autres...

    Bonne journée à tous et merci pour vos réponses

    Capture d’écran 2016-10-15 à 12.17.30.png

    Affaire réglé,

    ça fonctionne dans DSM et dans mon reverseProxy.

  21. je confirme que c'est ce que j'ai fait, par la force des choses d'ailleurs (j'en ai eu besoin pour nginx).

    je me suis mal exprimé, pardon.

    quand j'ai dit que la clé n'était pas protégée par un mot de passe, je voulais dire décryptée. mon fichier de base commence par ça :

    -----BEGIN RSA PRIVATE KEY-----

    Proc-Type: 4,ENCRYPTED

    La clé non protégée que je veux injecter dans DSM (notamment pour FTPS et OpenVPN) ne contient pas Proc-Type: 4,ENCRYPTED.

    en tout cas merci pour la tentative.

     

  22. Il y a 9 heures, Fenrir a dit :
    • 1) cette même clef et ce même certificat fonctionnent correctement avec nginx ?
    • 2) tu as bien créé un certificat signé en sha256 (le sha1 est déprécié). ?
    • 3) tu n'inverses pas le certificat et la chaine lors de l'import ?

    Bonjour et merci de m'avoir lu.

    1) oui, d'ou mon incompréhension. je l'utilise tous les jours avec mon reverseProxy nginx pour accéder à des services hébergés sur mon nas (DSM, sites web pour de la domotique, gitlab, ...) ou même ma freebox ou mon routeur, via des url de type https://monservice.mondomaine.fr. et le certificat est correctement reconnu quelque soit le navigateur et l'os.

    entre perso et boulot, j'utilise windows 7, windows 10, Linux et MacOS quotidiennement avec chrome( sur les 3 os), firefox (linux) et safari (macos forcement...) :cry:

    2) certains. j'ai déjà changé mon certificat il y a un moment, chrome (42+ si je me souviens bien) n'indiquant plus un cadena vert, mais un gris avec triangle jaune si le certificat était en sha1 et puis si je regarde les détails de mon certificat (depuis un navigateur, à l'une des url du reverseProxy) histoire de revérifier c'est bien du sha256 et enfin StartSSL ne laisse plus le choix et le certificat que je veux installer date d'il y a moins de 15 jours.

    3) vérifié et revérifié avant de poster, ou alors je me méprends complètement. Mais mon fichier clé commence par -----BEGIN RSA PRIVATE KEY---- et je suis sûr qu'il n'est pas protégé par un mot de passe. Mon certificat, lui, commence par -----BEGIN CERTIFICATE-----. normalement c'est explicite.

    Le doute que j'ai eu c'est sur le format de la clé. j'utilise directement celle que j'ai eu avec StartSSL et que j'utilise dans nginx :

    ssl on;
    ssl_certificate      /pathDirReverseProxy/moncertificat.crt;
    ssl_certificate_key  /pathDirReverseProxy/moncertificat_noPass.key;
    

    du coup j'ai essayé avec d'autre format notamment un  pem (obtenu en convertissant mon fichier.key via un format p12) qui commence par :

    Bag Attributes
        localKeyID: ...
    Key Attributes: <No Attributes>
    -----BEGIN PRIVATE KEY-----
    

    l'autre doute concernait le certificat, surtout le certificat intermédiaire (devais-je concaténer le certificat root à l'intermédiaire ou pas), mais aucun essai n'a été concluant.

    pour nginx tout est concaténé dans un seul fichier "bundle", mais j'ai bien à disposition monCertificat.crt, Intermediate.crt et root.crt

    J'ai vraiment tout essayé et pas mal cherché sur internet avant de poster ici.

    j'ai même par dépit essayé en mettant le même nom (sauf extension) à la clé et au certificat... quand la logique je marche plus, on essaye tout...:confused:

    mais je dois visiblement passer à coté de quelque chose...

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.