Ostrzeżenie: ta strona dotyczy starszych interfejsów API Google – interfejsów API danych Google – dotyczy tylko interfejsów API wymienionych w katalogu interfejsów API danych Google, z których wiele zostało zastąpionych nowszych. Informacje na temat konkretnego nowego interfejsu API można znaleźć w dokumentacji nowego interfejsu API. Informacje o autoryzowaniu żądań za pomocą nowszego interfejsu API znajdziesz w artykule Uwierzytelnianie i autoryzacja kont Google.

Ten dokument opisuje, jak korzystać z bibliotek klienta interfejsu Google Data API do łączenia się z Uwierzytelnianiem Google dla aplikacji internetowych.

Interfejs AuthSub umożliwia aplikacji internetowej dostęp do usługi Google w imieniu użytkownika. Aby zapewnić wysoki poziom bezpieczeństwa, interfejs AuthSub pozwala aplikacji uzyskać token uwierzytelniania bez konieczności obsługi danych logowania konta użytkownika.

Biblioteki klienta interfejsu API danych Google udostępniają metody, które ułatwiają korzystanie z AuthSub w aplikacji internetowej. Konkretnie chodzi tu o metody tworzenia adresu URL żądania, pozyskania tokena uwierzytelniania jednorazowego, wymiany tokena jednorazowego dla tokena sesji i podpisania żądania.

Uwaga: biblioteka klienta JavaScript ma własny smak AuthSub. Informacje o korzystaniu z AuthSubJS w aplikacjach JavaScript znajdziesz w artykule Korzystanie z uwierzytelniania „AuthSub” w Bibliotece klienta JavaScript.

Odbiorcy

Ten dokument jest przeznaczony dla programistów, którzy chcą, aby ich aplikacje internetowe miały dostęp do usług Google w imieniu użytkowników przy użyciu bibliotek klienta interfejsów API danych Google.

W tym dokumencie założono, że znasz interfejs AuthSub i ogólny opis procesu wprowadzania AuthSub do aplikacji internetowej. Pełny opis protokołu AuthSub znajdziesz w artykule Uwierzytelnianie AuthSub dla aplikacji internetowych.

Używanie interfejsów AuthSub i interfejsów API danych Google bez bibliotek klienta

Jeśli chcesz, aby klient aplikacji internetowej wchodził w interakcję z usługą danych Google, korzystając z systemu uwierzytelniania AuthSub, wszystko, co musisz wiedzieć, znajdziesz w artykule UwierzytelnianieSub w aplikacjach internetowych. Nie musisz korzystać z bibliotek klienta interfejsów API danych Google.

Oto zarys sposobu uwierzytelniania aplikacji za pomocą AuthSub:

Aplikacja tworzy odpowiedni adres URL AuthSub, a następnie przesyła użytkownika na ten adres, aby się zalogować. System AuthSub odsyła użytkownika do adresu URL określonego w Twojej witrynie i zwraca token jednorazowy. Aplikacja opcjonalnie wymienia ten token na token sesji, a następnie aplikacja wysyła token w nagłówku autoryzacji przy każdym żądaniu wysłanym do usługi.

Biblioteki klienta interfejsów API danych Google upraszczają ten proces przez obsługę różnych szczegółów. W tym dokumencie opisujemy, jak to zrobić.

Praca z AuthSub i interfejsami API danych Google: przykłady z biblioteki klienta

Ta sekcja zawiera przykład użycia metod biblioteki klienta interfejsu Google Data API do wykonania czynności opisanych w sekcji „Working With AuthSub” (Praca z uwierzytelnianiem) w dokumentacji AuthSub.

W tym przykładzie integrujemy interfejs AuthSub z aplikacją internetową, która współdziała z Kalendarzem Google (chociaż nie trzeba nic wiedzieć o Kalendarzu Google, aby skorzystać z przykładu). W przykładzie założono, że aplikacja internetowa jest hostowana w domenie example.com.

Wybierz typ tokena, którego chcesz użyć (session=0 lub session=1)

Możesz używać tokenów jednorazowych (session=0) lub tokenów sesji (session=1). Ten dokument będzie wykorzystywać tokeny sesji, ponieważ są one bardziej przydatne w aplikacjach, które wysyłają wiele żądań do interfejsu API. Zgodnie z informacjami w dokumentacji AuthSub, jeśli zdecydujesz się używać tokenów sesji w aplikacji internetowej, musisz samodzielnie zarządzać miejscem na tokeny. Ten dokument nie dotyczy zarządzania tokenami. Tokenów żądanych z session=0 nie można później wymienić (uaktualnić) na tokeny sesji o dłuższym czasie ważności.

Zdecyduj, czy chcesz zarejestrować swoją aplikację internetową (secure=0 czy secure=1)

Uwierzytelnianie SubSub może być używane w 3 różnych trybach: niezarejestrowanym, zarejestrowanym i zarejestrowanym ze zwiększonym zabezpieczeniami. Pozostała część tego dokumentu będzie odnosić się do ostatniej opcji jako bezpiecznego uwierzytelniania AuthSub. Tryb niezarejestrowany/zarejestrowany jest prostszy w konfiguracji niż bezpieczny protokół AuthSub, ale zachęcamy do korzystania z bezpiecznych tokenów.

Jak się zarejestrować

Wybranie opcji Rejestracja w aplikacjach internetowych daje następujące korzyści:

1. Wyższy poziom bezpieczeństwa.
2. jest zaufane przez Google (użytkownik nie widzi ostrzeżeń na stronie autoryzacji Google);

Zarejestrowana + bezpieczna autoryzacja

Jeśli zdecydujesz się na korzystanie z bezpiecznego uwierzytelniania AuthSub, oprócz zarejestrowania aplikacji internetowej musisz utworzyć samodzielnie podpisany klucz prywatny RSA i publiczną parę certyfikatu. Przykłady tworzenia certyfikatów X.509 znajdziesz poniżej (w sekcji Generowanie kluczy i certyfikatów do użytku w trybie zarejestrowanym) poniżej.

Określ zakres dostępu do danych

Każda usługa Google określa wartość scope, która określa (i prawdopodobnie zawęża) dostęp tokena do danych użytkownika. Listę dostępnych wartości scope znajdziesz w Najczęstszych pytaniach.

Postanowiliśmy skorzystać z interfejsu Google Calendar API, dlatego scope to http://www.google.com/calendar/feeds/.

Uwaga: zawsze ustawiaj wartość zakresu na najszerszy możliwy adres URL, chyba że chcesz zastosować bardziej restrykcyjne ograniczenia. Na przykład węższy zakres, taki jak scope=http://www.google.com/calendar/feeds/default/allcalendars/full, ogranicza dostęp do tokena tylko do wszystkich kalendarzy lub pełnego kanału. Korzystanie z scope=http://www.google.com/calendar/feeds/ umożliwia dostęp do wszystkich kanałów Kalendarza: http://www.google.com/calendar/feeds/*.

Tokeny wielozakresowe

Aby utworzyć tokeny mające dostęp do wielu interfejsów Google Data API, rozdziel każdy zakres spacją za pomocą adresu URL. Przykład poniżej tworzy token, który będzie miał dostęp zarówno do Kontaktów Google, jak i do Kalendarza Google.

scope=http://www.google.com/calendar/feeds/%20http://www.google.com/m8/feeds/

Poproś o token uwierzytelniania jednorazowego

Aby uzyskać token AuthSub dla danego użytkownika i danej usługi, aplikacja musi przekierować użytkownika do adresu URL AuthSubRequest, który zachęca do zalogowania się na konto Google. Więcej informacji o adresie URL AuthSubRequest znajdziesz w pełnym uwierzytelnianiem aplikacji AuthSub do aplikacji internetowych.

Aby utworzyć adres URL AuthSubRequest w aplikacji, w przypadku każdej biblioteki klienta użyj tych parametrów:

import com.google.gdata.client.*;

String nextUrl = "http://www.example.com/RetrieveToken.jsp";
String scope = "http://www.google.com/calendar/feeds/";
boolean secure = false;  // set secure=true to request secure AuthSub tokens
boolean session = true;
String authSubUrl = AuthSubUtil.getRequestUrl(nextUrl, scope, secure, session);

import com.google.gdata.client.*;

String hostedDomain = "example.com";
String nextUrl = "http://www.example.com/RetrieveToken.jsp";
String scope = "http://www.google.com/calendar/feeds/";
boolean secure = false;  // set secure=true to request AuthSub tokens
boolean session = true;
String authSubUrl = AuthSubUtil.getRequestUrl(hostedDomain, nextUrl, scope, secure, session);

using Google.GData.Client;

String nextUrl = "http://www.example.com/RetrieveToken.aspx";
String scope = "http://www.google.com/calendar/feeds/";
bool secure = false; // set secure=true to request secure AuthSub tokens
bool session = true;
String authSubUrl = AuthSubUtil.getRequestUrl(nextUrl, scope, secure, session);

using Google.GData.Client;

String hostedDomain = "example.com";
String nextUrl = "http://www.example.com/RetrieveToken.aspx";
String scope = "http://www.google.com/calendar/feeds/";
bool secure = false; // set secure=true to request secure AuthSub tokens
bool session = true;
String authSubUrl = AuthSubUtil.getRequestUrl(hostedDomain, nextUrl, scope, secure, session);

require_once 'Zend/Loader.php';
Zend_Loader::loadClass('Zend_Gdata_AuthSub');

$nextUrl = 'http://www.example.com/RetrieveToken.php';
$scope = 'http://www.google.com/calendar/feeds/';
$secure = 0;  // set $secure=1 to request secure AuthSub tokens
$session = 1;
$authSubUrl = Zend_Gdata_AuthSub::getAuthSubTokenUri($nextUrl, $scope, $secure, $session);

require_once 'Zend/Loader.php';
Zend_Loader::loadClass('Zend_Gdata_AuthSub');

$hostedDomain = 'example.com';
$nextUrl = 'http://www.example.com/RetrieveToken.php';
$scope = 'http://www.google.com/calendar/feeds/';
$secure = 0;  // set $secure=1 to request secure AuthSub tokens
$session = 1;
$authSubUrl = Zend_Gdata_AuthSub::getAuthSubTokenUri($nextUrl, $scope, $secure, $session) . '&hd=' . $hostedDomain;

import gdata.auth

next = 'http://www.example.com/RetrieveToken.pyc'
scope = 'http://www.google.com/calendar/feeds/'
secure = False  # set secure=True to request secure AuthSub tokens
session = True
auth_sub_url = gdata.auth.GenerateAuthSubRequestUrl(next, scope, secure=secure, session=session)

import gdata.auth

hosted_domain = 'example.com'
next = 'http://www.example.com/RetrieveToken.pyc'
scope = 'http://www.google.com/calendar/feeds/'
secure = False  # set secure=True to request secure AuthSub tokens
session = True
auth_sub_url = gdata.auth.GenerateAuthSubRequestUrl(next, scope, secure=secure, session=session, domain=hosted_domain)

Po utworzeniu adresu URL „next” aplikacja może używać go na różne sposoby do wysyłania użytkownika do modułu obsługi AuthSubRequest. Najczęstszym podejściem jest wyświetlanie strony z informacją dla użytkownika, że musi kliknąć link, aby upoważnić aplikację do uzyskania dostępu do konta Google, a następnie załączenie do niego adresu URL żądania. Możesz na przykład wyświetlić w aplikacji internetowej ten ciąg znaków:

String authorizationUrl =
        "<p>MyApp needs access to your Google Calendar account to read your Calendar feed. " +
        "To authorize MyApp to access your account, <a href=\"" + authSubUrl + "\">log in to your account</a>.</p>";

Użytkownik klika link do strony AuthSub w Google i się loguje. System AuthSub następnie przekierowuje użytkownika z powrotem do aplikacji, używając podanego przez Ciebie adresu URL „następnego”.

Wyodrębnij token jednorazowy

Gdy Google przekieruje Cię z powrotem do Twojej aplikacji, token zostanie dołączony do adresu URL następnego ciągu jako parametru zapytania. W powyższych przykładach gdy użytkownik się zaloguje, Google przekierowuje na adres URL taki jak http://www.example.com/RetrieveToken?token=DQAADKEDE. Aplikacja powinna wyodrębnić wartość tokena z parametru zapytania o adres URL.

Jeśli Twoja aplikacja ustawi plik cookie uwierzytelniania w przeglądarce użytkownika przed wysłaniem go do systemu AuthSub, to gdy Google wykona przekierowanie z powrotem na URL „kolejny”, aplikacja będzie mogła odczytać plik cookie uwierzytelniania, by zidentyfikować użytkownika, który dotarł do tego adresu. Taki plik cookie może służyć do powiązania identyfikatora użytkownika w aplikacji z tokenem AuthSub pobranym od Google.

Biblioteki klienta udostępniają wygodne metody wyodrębniania tokena jednorazowego:

String singleUseToken = AuthSubUtil.getTokenFromReply(httpServletRequest.getQueryString());

String singleUseToken = Request.QueryString["token"];
// or
String singleUseToken = AuthSubUtil.getTokenFromReply(new Uri(Request.QueryString));

$singleUseToken = $_GET['token'];

current_url = 'http://' + req.hostname + req.unparsed_uri
# Unlike the other calls, extract_auth_sub_token_from_url() will create an AuthSubToken or SecureAuthSubToken object.
# Use str(single_use_token) to return the token's string value.
single_use_token = gdata.auth.extract_auth_sub_token_from_url(current_url)

f = open('/path/to/yourRSAPrivateKey.pem')
rsa_key = f.read()
f.close()
current_url = 'http://' + req.hostname + req.unparsed_uri
# Unlike the other calls, extract_auth_sub_token_from_url() will create an AuthSubToken or SecureAuthSubToken object.
# Use str(single_use_token) to return the token's string value.
single_use_token = gdata.auth.extract_auth_sub_token_from_url(current_url, rsa_key=rsa_key)

Poproś o token sesji

Token pobierany z adresu URL jest zawsze tokenem jednorazowym. Następnym krokiem jest uaktualnienie tego tokena dla długotrwałego tokena sesji przy użyciu adresu URL AuthSubSessionToken zgodnie z pełną dokumentacją AuthSub Authentication for Web Applications. Jeśli używasz bezpiecznego uwierzytelniania AuthSub, musisz ustawić klucz prywatny RSA przed wymianą. Oto kilka przykładów użycia poszczególnych bibliotek klienta:

import com.google.gdata.client.*;
import com.google.gdata.client.calendar.*;

String sessionToken = AuthSubUtil.exchangeForSessionToken(singleUseToken, null);

CalendarService calendarService = new CalendarService("google-ExampleApp-v1.0");
calendarService.setAuthSubToken(sessionToken, null);

// ready to interact with Calendar feeds

import com.google.gdata.client.*;
import com.google.gdata.client.calendar.*;

java.security.PrivateKey privateKey =
    AuthSubUtil.getPrivateKeyFromKeystore("AuthSubExample.jks", "privKeyPa$$word", "AuthSubExample", "privKeyPa$$word");
String sessionToken = AuthSubUtil.exchangeForSessionToken(singleUseToken, privateKey);

CalendarService calendarService = new CalendarService("google-ExampleApp-v1.0");
calendarService.setAuthSubToken(sessionToken, privateKey);

// ready to interact with Calendar feeds

using Google.GData.Client;
using Google.GData.Calendar;

String sessionToken = AuthSubUtil.exchangeForSessionToken(singleUseToken, null).ToString();

GAuthSubRequestFactory authFactory = new GAuthSubRequestFactory("cl", "google-ExampleApp-v1.0");
authFactory.Token = (String) sessionToken;

CalendarService calendarService = new CalendarService(authFactory.ApplicationName);
calendarService.RequestFactory = authFactory;

// ready to interact with Calendar feeds

using Google.GData.Client;
using Google.GData.Calendar;

protected AsymmetricAlgorithm getRsaKey()
{
  X509Certificate2 cert = new X509Certificate2("C:/MyAspSite/test_cert.pfx", "privKeyPa$$word");
  RSACryptoServiceProvider privateKey = cert.PrivateKey as RSACryptoServiceProvider;
  return privateKey;
}

AsymmetricAlgorithm rsaKey = getRsaKey();
String sessionToken = AuthSubUtil.exchangeForSessionToken(singleUseToken, rsaKey).ToString();

GAuthSubRequestFactory authFactory = new GAuthSubRequestFactory("cl", "google-ExampleApp-v1.0");
authFactory.Token = (String) sessionToken;
authFactory.PrivateKey = rsaKey;

CalendarService calendarService = new CalendarService(authFactory.ApplicationName);
calendarService.RequestFactory = authFactory;

// ready to interact with Calendar feeds

require_once 'Zend/Loader.php';
Zend_Loader::loadClass('Zend_Gdata_AuthSub');
Zend_Loader::loadClass('Zend_Gdata_Calendar');

$sessionToken = Zend_Gdata_AuthSub::getAuthSubSessionToken($singleUseToken);

// Create a Calendar service object and set the session token for subsequent requests
$calendarService = new Zend_Gdata_Calendar(null, 'google-ExampleApp-v1.0');
$calendarService->setAuthSubToken($sessionToken);

// ready to interact with Calendar feeds

require_once 'Zend/Loader.php';
Zend_Loader::loadClass('Zend_Gdata_AuthSub');
Zend_Loader::loadClass('Zend_Gdata_Calendar');

$client = new Zend_Gdata_HttpClient();
$client->setAuthSubPrivateKeyFile('/path/to/myrsakey.pem', null, true);
$sessionToken = Zend_Gdata_AuthSub::getAuthSubSessionToken($singleUseToken, $client);

$calendarService = new Zend_Gdata_Calendar($client, 'google-ExampleApp-v1.0');
$calendarService->setAuthSubToken($sessionToken);

// ready to interact with Calendar feeds

import gdata.calendar
import gdata.calendar.service

calendar_service = gdata.calendar.service.CalendarService()
calendar_service.UpgradeToSessionToken(single_use_token)  # calls gdata.service.SetAuthSubToken() for you

# ready to interact with Calendar feeds

Uwaga: w przypadku bezpiecznego uwierzytelniania klucz prywatny nie jest wysyłany przez sieć. Biblioteki klienta wysyłają unikalny podpis wygenerowany przez podpisanie żądania kluczem, a nie kluczem.

Używanie tokena sesji

Tokenu sesji możesz używać do uwierzytelniania żądań wysyłanych do serwera, umieszczając go w nagłówku autoryzacji, tak jak to opisano w dokumentacji AuthSub.

Po ustawieniu tokena sesji możesz używać standardowej wywołania biblioteki klienta interfejsów API danych Google do interakcji z usługą, bez zastanowienia się nad tokenem. Szczegółowe informacje znajdziesz w dokumentacji biblioteki klienta oraz przewodniku dla programistów dotyczącym danych interfejsu Google Data API w przypadku danej usługi i języka.

Pobieram informacje o tokenie sesji

Jeśli chcesz sprawdzić, czy klient i serwer uzgadniają parametry tokena, możesz przekazać go do modułu obsługi AuthSubTokenInfo. Ta funkcja zwróci zestaw par nazwa-wartość, które zawierają informacje o tokenie.

Map<String, String> tokenInfo = AuthSubUtil.getTokenInfo(sessionToken, null);

Map<String, String> tokenInfo = AuthSubUtil.getTokenInfo(sessionToken, privateKey);

Dictionary<String, String> tokenInfo = AuthSubUtil.GetTokenInfo(sessionToken, null);

Dictionary<String, String> tokenInfo = AuthSubUtil.GetTokenInfo(sessionToken, privateKey);

$tokenInfo = Zend_Gdata_AuthSub::getAuthSubTokenInfo($sessionToken);

$tokenInfo = Zend_Gdata_AuthSub::getAuthSubTokenInfo($sessionToken, $client);

token_info = calendar_service.AuthSubTokenInfo()

Unieważnianie tokena sesji

Tokeny sesji AuthSub nie wygasają. Klient może przechowywać token sesji tak długo, jak to konieczne.

Gdy klient zakończy korzystanie z tokena sesji, może go unieważnić za pomocą modułu obsługi AuthSubRevokeToken, jak opisano w dokumentacji AuthSub.

Jeśli na przykład chcesz zarządzać tokenami w tradycyjny sposób, Twój klient może uzyskać token na początku sesji użytkownika i unieważnić go pod koniec sesji użytkownika.

Aby unieważnić token, użyj tych elementów w każdej bibliotece klienta:

AuthSubUtil.revokeToken(sessionToken, null);

AuthSubUtil.revokeToken(sessionToken, privateKey);

AuthSubUtil.revokeToken(sessionToken, null);

AuthSubUtil.revokeToken(sessionToken, privateKey);

$wasRevoked = Zend_Gdata_AuthSub::AuthSubRevokeToken($sessionToken);

$wasRevoked = Zend_Gdata_AuthSub::AuthSubRevokeToken($sessionToken, $client);

calendar_service.RevokeAuthSubToken()

Dodatkowe materiały i przykłady

• Przykłady AuthSub na blogu Google Data API – wskazówki
• Biblioteka klienta Pythona Przykład AuthSub
• Biblioteka klienta Java Przykład SubAuth
• Artykuł: Używanie AuthSub z biblioteką klienta .NET
• Artykuł: Korzystanie z uwierzytelniania „AuthSub” w bibliotece klienta JavaScript

Powrót do góry

Generowanie samodzielnie podpisanego klucza prywatnego i certyfikatu publicznego do użycia z bezpiecznym AuthSub

Klucz prywatny jest używany do generowania podpisu, który musi być dołączony do każdego żądania. Google używa klucza publicznego umieszczonego w certyfikacie do weryfikowania podpisu. Klucz publiczny musi być 1024-bitowym kluczem RSA zakodowanym w certyfikacie X.509 w formacie PEM. Certyfikat należy przesłać do Google w momencie rejestracji.

Poniższe sekcje zawierają przykłady generowania kluczy i certyfikatów za pomocą 2 konkretnych narzędzi: narzędzia OpenSSL i narzędzia Java keytool.

Te przykłady nie dotyczą konkretnych interfejsów API danych Google. Do generowania kluczy możesz używać tych samych narzędzi.

Przykład

Generowanie kluczy przy użyciu OpenSSL

Aby utworzyć parę kluczy RSA i odpowiadający im certyfikat, możesz użyć tego polecenia:

# Generate the RSA keys and certificate
openssl req -x509 -nodes -days 365 -newkey rsa:1024 -sha1 -subj \
  '/C=US/ST=CA/L=Mountain View/CN=www.example.com' -keyout \
  myrsakey.pem -out /tmp/myrsacert.pem

Ostrzeżenie: dodanie parametru -nodes spowoduje utworzenie klucza prywatnego bez hasła. Warto jednak pominąć ten parametr, aby zwiększyć bezpieczeństwo.

Parametr -sha1 określa, że klucz będzie używany do generowania podpisów SHA1.

Parametr -subj określa tożsamość aplikacji, którą reprezentuje certyfikat.

Parametr -keyout określa plik, który zawiera klucze. Ten plik zawiera informacje poufne, więc powinien być chroniony i nie należy go nikomu udostępniać.

Parametr -out określa plik zawierający certyfikat w formacie PEM (który można wysłać do Google podczas rejestracji).

Generowanie kluczy dla klienta .NET

Platforma .NET nie rozpoznaje kluczy ani certyfikatów przechowywanych w formacie PEM. W związku z tym po utworzeniu pliku .pem musisz wykonać dodatkowy krok:

openssl pkcs12 -export -in test_cert.pem -inkey myrsacert.pem -out myrsacert.pfx -name "Testing Certificate"

W tym kroku zostanie wygenerowany plik PFX z klucza prywatnego i certyfikatu. Ten plik można zaimportować do biblioteki klienta .NET, aby podpisywać cyfrowe żądania wysyłane do interfejsów API danych Google.

Generowanie kluczy dla klienta Java

Klient języka Java akceptuje klucze prywatne w formacie PKCS#8. Po wygenerowaniu klucza lub certyfikatu zgodnie z powyższymi instrukcjami utwórz plik .pk8 z wygenerowanego pliku .pem:

openssl pkcs8 -in myrsakey.pem -topk8 -nocrypt -out myrsakey.pk8

Możesz też użyć magazynu kluczy Java i narzędzia keykey do utworzenia pary kluczy RSA i odpowiedniego certyfikatu. Użyj tego polecenia:

# Generate the RSA keys and certificate
keytool -genkey -v -alias Example -keystore ./Example.jks\
  -keyalg RSA -sigalg SHA1withRSA\
  -dname "CN=www.example.com, OU=Engineering, O=My_Company, L=Mountain  View, ST=CA, C=US"\
  -storepass changeme -keypass changeme

Ostrzeżenie: „changeme” nie jest dobrym hasłem. To tylko przykład.

Parametr -dname określa tożsamość aplikacji, którą reprezentuje certyfikat. Parametr -storepass określa hasło, które ma chronić magazyn kluczy. Parametr -keypass określa hasło, które ma chronić klucz prywatny.

Aby zapisać certyfikat w pliku, którego można użyć w narzędziu ManageDomains, użyj tego polecenia:

# Output the public certificate to a file
keytool -export -rfc -keystore ./Example.jks -storepass changeme \
  -alias Example -file mycert.pem

Powrót do góry