0
votes

Communication SSL gRPC pour .NET Framework vers .NET Core Server

Puis-je utiliser le client C # Full .NET Framework avec le client principal C # .NET avec un canal sécurisé.?

Pouvez-vous m'indiquer quelques exemples où cela est fait? Je n'ai trouvé nulle part si cela peut être fait ou si cela ne peut pas être fait.

Détail: J'ai fait un exemple en utilisant le client .NET Framework avec Grpc C # Github comme référence et le client .NET Core avec cet exemple de Grpc dotnet comme référence. J'ai pu établir un canal de communication non sécurisé avec

nouveau canal ("127.0.0.1", 5000, ChannelCredentials.Insecure)

et le port Non-Https ouvert en 5000 sur le serveur ASP.NET Core.

Quand j'essaye de me connecter avec

var channel = new Channel ("127.0.0.1", 5001, new SslCredentials ());

vers le port Https 5000 dans ASP.NET Core ServerI

Comment puis-je utiliser un canal sécurisé pour communiquer. Je souhaite utiliser la même combinaison pfx + mot de passe.


0 commentaires

3 Réponses :


0
votes

J'ai eu un peu de chance avec cette réponse . Comme l'OP, je ne l'ai pas encore fait fonctionner à distance. Gardez à l'esprit que gRPC n'est pas encore pris en charge par IIS, vous devrez donc également trouver une méthode d'hébergement alternative.


4 commentaires

Je l'ai fait fonctionner. J'ai ajouté ma solution en tant que réponse ici [ stackoverflow.com/a/63041837/6128864] et ici [stackoverflow.com/a/63041806/6128864]


De plus, je ne voudrais jamais utiliser IIS si possible.


Pourquoi ne voudriez-vous jamais utiliser IIS? Cela semble être un proxy inverse parfaitement valide, et il offre les avantages supplémentaires en termes de sécurité et de performances d'un serveur Web complet.


Pour éviter d'utiliser la machine Windows si possible. IIS est uniquement Windows. Si je pouvais utiliser le serveur ASP.NET Core, j'opterais toujours pour un système distribué basé sur docker avec un proxy inverse open source comme nginx plutôt qu'un IIS.



1
votes

Découvrez ma question et ma réponse ici . J'ai créé un exemple de base qui peut être utile: https://github.com/angelagyang/GRPCProtobufExample Vous pouvez configurer un certificat client en créant un KeyCertificatePair pour passer dans SslCredentials . Vous aurez besoin de trois chaînes codées PEM:

  1. Chaîne de certificats client encodée PEM
  2. Clé privée codée PEM
  3. Certificat SSL de serveur codé PEM.

Voici un exemple de configuration:

var keyCertPair = new KeyCertificatePair(clientsslcert.pem, privatekey.pem); 
var channelCreds = new SslCredentials(serversslcert.pem, keyCertPair);

À des fins de test, j'ai trouvé ces PEM de test sont utiles . J'ai utilisé OpenSSL pour convertir PFX au format PEM. De plus, cet article parle un peu plus des différentes chaînes PEM et des raisons pour lesquelles le client doit explicitement faire confiance au serveur.


3 commentaires

C'est une bonne solution, mais je voudrais réduire le code au minimum possible. Je l'ai fait fonctionner sans la partie keyCertPair, mais en lisant le pem sous forme de texte. Veuillez consulter ma solution.


Heureux de l'entendre! Le KeyCertificatePair ne doit être utilisé que si vous souhaitez implémenter la vérification du certificat client (c'est-à-dire si le serveur souhaite vérifier le certificat du client pour une couche de sécurité supplémentaire).


J'ai trouvé un moyen sans avoir besoin de stocker le pem côté client, peut-être que c'est également utile pour d'autres personnes: stackoverflow.com/a/ 66041094/727250



1
votes

Je publie cette réponse pour le bien de la prochaine personne à la recherche de la solution. J'ai publié ma solution dans une question de cas d'utilisation similaire dans SO après l'avoir fait fonctionner ici et ici

- Ci-dessous est copié de Ma propre réponse.

Sur SSL ou non, vous devez activer Http2 dans Serveur ASP.NET Core. Donc, dans appsettings.json, faites ceci.

SslCredentials secureCredentials = new SslCredentials(File.ReadAllText("<DiskLocationTo the Folder>/certificate.pem"))
var channel = new Channel("localhost", 5001, secureCredentials);

Client .NET Framework non sécurisé + ASP.NET Core Server

  • Serveur ASP.NET Core
    1. Supprimez app.UseHttpsRedirection () et app.UseHsts () dans la classe StartUp ConfigureServices (application IApplicationBuilder) code>;
    2. Exposez le port non sécurisé, généralement 80 ou 5000 pendant le développement.
    3. Utilisez le code ci-dessous pour créer un canal non sécurisé dans le client .NET Framework.
openssl pkcs12 -in "<DiskLocationOfPfx>\ProjectName.pfx" -out "<TargetLocation>\certifcate.pem" -clcerts

Connexion SSL sécurisée .NET Framework Client + ASP.NET Core Server

Je l'ai fait fonctionner avec le port SSL en en utilisant le même certificat de serveur au format .pem dans le client.

SslCredentials secureCredentials = new SslCredentials(File.ReadAllText("certificate.pem"));
var channel = new Channel("localhost", 5001, secureCredentials);

Un peu d'explication. Un modèle ASP.NETCore dans VS 2019 utilise un certificat de développement avec le fichier pfx à % AppData% \ ASP.NET \ Https \ ProjectName.pfx et password = % AppData% \ Microsoft \ UserSecrets \ {UserSecretsId} \ secrets.json {: Kestrel: Certificates: Development: Password} Value Vous pouvez obtenir l'ID UserSecretsId à partir de ProjectName.csproj . Ce sera différent pour chaque projet ASP.NET Core.

J'ai utilisé la commande ci-dessous pour convertir la combinaison pfx + mot de passe en un fichier certificate.pem .

XXX

Cela demandera le mot de passe pfx. Utilisez le mot de passe du secrets.json ci-dessus .

Donnez une phrase de passe pour le certificate.pem à générer (au moins 4 lettres).

Copiez ce cerificate.pem pour que le client gRPC .NET Framework puisse accéder et l'utiliser dans

var channel = new Channel("localhost", 5001, ChannelCredentials.Insecure);

Notez que le port 5001 I utilisé est le port SSL de mon application ASP.NET Core.

Pour les scénarios de production

Utilisez un certificat valide de l'autorité de signature de certificat et utilisez le même certificat dans Serveur ASP.NET Core et client .NET Framework comme pfx et pem respectivement.


0 commentaires