Jump to content

Cryptography

From MukeWiki

OpenSSH a OpenSSL

OpenSSH is a suite of secure networking utilities based on the Secure Shell (SSH) protocol, which provides a secure channel over an unsecured network in a client–server architecture, connecting an SSH client instance with an SSH server.

OpenSSL is a software library for applications that provide secure communications over computer networks. It is widely used by Internet servers, including the majority of HTTPS websites. Is a cryptography toolkit implementing Transport Layer Security (TLS v1) and now deprecated Secure Sockets Layer (SSL v2/v3) network protocols and related cryptography standards required by them.

Aky je rozdiel medzi OpenSSL a OpenSSH nie je jednoduche vysvetlit a na internete je mnozstvo relevantnych informacii. Obidvaja vytvaraju sifrovany kanal medzi dvoma stranami, cez ktory potom prebieha sifrovana vymena dat, komunikacia. SSL bol na zaciatku primarne navrhnuty pre HTTPS protokol a SSH ako nastroj pre bezpecny sietovy terminal. Protokoly by mali byt medzi sebou teoreticky zamenitelne. OpenSSH od roku 2014 znacne znizil zavislost na OpenSSL kniznici (hlavne kvoli roznym zranitelnostiam). Vo Fedore balik openssh ma zavislost na openssl-libs.

Pri SSL (dnes je uz SSL protokol zastaraly a mal by sa pouzivat len TLS protokol) je autorizacia volitelna, na rozdiel od SSH, kde je autorizacia stale obojstranna. SSH umoznuje rozne sposoby autorizacie, najcastejsie pomocou klucov. SSL pouziva certifikaty, resp. cely retazec certifikatov, ktorymi sa overuju autority. Alebo inymi slovami. SSH vytvara sifrovanu komunikaciu stale medzi klientom a serverom. SSL vytvory zabezpeceny kanal pomocou certifikatu, ktoremu ako autorite doverujeme, resp. si ho mozeme preverit.

SSH

ssh-keygen(1) can create a new SSH key pair by generating public and private type-of-key key pair. By default type-of-key (Fedora 38, openssh-9.0p1, 2023-05) is rsa with rsa-sha2-512 RSA signature variant. GitHub (for example) recommended ed25519 type-of-key. 

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/musinsky/.ssh/id_rsa):
Created directory '/home/musinsky/.ssh'.                                  # access: (0700/drwx------)
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/musinsky/.ssh/id_rsa          # access: (0600/-rw-------)
Your public key has been saved in /home/musinsky/.ssh/id_rsa.pub          # access: (0644/-rw-r--r--)

$ ssh-keygen -t ed25519 -C musinsky@gmail.com
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/musinsky/.ssh/id_ed25519): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/musinsky/.ssh/id_ed25519
Your public key has been saved in /home/musinsky/.ssh/id_ed25519.pub

~/.ssh/id_rsa and ~/.ssh/id_ed25519 contains the private key for authentication. These files contain sensitive data and should be readable by the user but not accessible by others (read/write/execute). ssh(1) will simply IGNORE a private key file if it is accessible by others.

~/.ssh/id_rsa.pub and ~/.ssh/id_ed25519.pub contains the public key for authentication. These files are not sensitive and can (but need not) be readable by anyone. 

# read a private OpenSSH format file and print an OpenSSH public key (create public key from the private key)

$ ssh-keygen -y -f ~/.ssh/id_rsa > id_rsa.recreate.pub   # without key comment
Enter passphrase for "/home/musinsky/.ssh/id_rsa":
The most commonly used types of SSH type-of-key (algorithm)
RSA rsa-sha2-512 (default), rsa-sha2-256, ssh-rsa (not recommended) compatible with old systems
ECDSA ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521
ED25519 ssh-ed25519 (since OpenSSH 6.5, 2014-01) best, but only since 2014 (RHEL 7)

Subor(y), ktory obsahuju private key (~/.ssh/id_type-of-key), zacina riadkom -----BEGIN OPENSSH PRIVATE KEY-----, resp. v starsich verziach OpenSSH -----BEGIN RSA PRIVATE KEY----- v zavislosti od pouziteho type-of-key.

Obsah suboru(ov), ktory obsahuje public key (~/.ssh/id_type-of-key.pub) by sa mal pridat do ~/.ssh/authorized_keys na vsetky pocitace, kde sa pouzivatel chce prihlasovat pomocou public key authentication. Public key sa moze jednoducho skopirovat (copy/paste) na pozadovany pocitac do suboru ~/.ssh/authorized_keys alebo pomocou ssh-copy-id(1) scriptu. 

# copy public key to ~/.ssh/authorized_keys file on remote host machine (create file with correct permissions)

$ ssh-copy-id musinsky@muke99.saske.sk                    # copy public key (ignore key comment)
$ ssh-copy-id -i .ssh/id_rsa.pub musinsky@muke99.saske.sk # copy content of file with public key (with comment)

Samotna autentifikacia medzi klientom a serverom prebieha sparovanim, overenim public a private key pair. To znamena, ze na strane klienta musi byt minimalne private key (~/.ssh/id_rsa) a na strane servera odpovedajuci public key ulozeny v (~/.ssh/authorized_keys). Po spravnom zadani hesla (passphrase) prejde autentifikacia a sme prihlaseni na vzdialenom serveri.

If your private key is encrypted with a passphrase (recommended), this passphrase must be entered every time you attempt to connect to an SSH server using public key authentication. Each individual invocation of ssh will need the passphrase in order to decrypt your private key before authentication can proceed. ssh-agent is a program which caches your decrypted private keys and provides them to SSH client programs on your behalf. In this arrangement, you must only provide your passphrase once, when adding your private key to the agent's cache. This facility can be of great convenience when making frequent SSH connections.

Once ssh-agent is running, you will need to add (automatically or manually) your private key to its cache ssh-add $HOME/.ssh/id_rsa. Will prompt you to enter your passphrase. Once your private key has been successfully added to the agent you will be able to make SSH connections without having to enter your passphrase. On most Linux systems, OpenSSH authentication agent is automatically configured and run at login, and no additional actions are required to use it.

V sucasnych Linux distribuciach je tento proces plne zautomatizovany a ssh-agent(1) spolupracuje s ssh-add(1) bez akehokolvek zasahu uzivatela. Na zaciatku zadame heslo (iba jeden krat) a dalej uz nebude potrebne zadavat heslo, kedze nasa identity uz bude ulozene v OpenSSH authentication agent (vacsinou az do restartu pocitaca, zavisi od nastavenia).

Zoznam vsetkych identities v OpenSSH authentication agent je mozne vypisat prikazom ssh-add -l # -L, vymazanie vsetkych identities prikazom ssh-add -D. V pripade problemoch mozeme potrebny private key identity pridat "manualne" ssh-add $HOME/.ssh/id_rsa, pripadne bez options pre default identity.

Na SSH server je v principe mozne prihlasit sa aj v pripade ak na strane klienta chyba public key (~/.ssh/id_rsa.pub). Samotna autentifikacia medzi klientom (~/.ssh/id_rsa) a serverom (~/.ssh/authorized_keys) prebehne po zadani hesla (passphrase), ale nebude mozne vyuzivat OpenSSH authentication agent a pri kazdom dalsom prihlasovani budeme znova zadavat heslo.

Vacsina problemov pri SSH prihlasovani je spojena s pravami a vlastnictvom potrebnych suborov "Authentication refused: bad ownership or modes". Na strane servera pozerame journal journalctl -u sshd.service, resp. pre starsie systemy tail /var/log/secure. 

# permissions by default (OpenSSH_9.0p1, OpenSSL 3.0.8, Fedora 38, 2023-05)
# see also ssh(1) section FILES

/home/musinsky/                         # (0700/drwx------)
/home/musinsky/.ssh/                    # (0700/drwx------)
/home/musinsky/.ssh/id_rsa              # (0600/-rw-------) can not be accessible by others, only owner
/home/musinsky/.ssh/id_rsa.pub          # (0644/-rw-r--r--)
/home/musinsky/.ssh/authorized_keys     # (0600/-rw-------)

SSL

Dalej budeme predpokladat len sifrovanie pre web stranky, t.j. HTTPS komunikacny protokol (HTTP over TLS, SSL was deprecated in June 2015).

Ako teda Firefox "doveruje" roznym web strankam ?
Firefox - Settings: Privacy & Security - Certificates - View Certificates: Certificate Manager - Authorities => tu je zoznam vsetkych certifikatov, ktorym doveruje Firefox, resp. certifikaty, ktore su distribuovane operacnym systemom. Ide o tzv. korenove (root) certifikaty, ktore stoja v retazci (chain) certifikatov na vrchole a ktorym "bezvyhradne" doverujeme, t.j. su povazovane za autority. Takychto certifikovanych autorit je v systeme niekolko desiatok az stoviek.

Pre stranku https://www.google.com nam Firefox oznamuje: "You are securely connected to this site. Verified by: Google Trust Services LLC". Po zobrazeni certifikatu (More information: Page Info - Security - View Certificate) mozeme vidiet cely retazec certifikatov, ktore sa navzajom preveruju, resp. podpisuju.

Certificates chain for https://www.google.com
Certificate *.google.com GTS CA 1C3 GTS Root R1 GlobalSign Root CA
Subject Name *.google.com Google Trust Services LLC
GTS CA 1C3 		Google Trust Services LLC
GTS Root R1 		GlobalSign nv-sa
GlobalSign Root CA
Issuer Name Google Trust Services LLC
GTS CA 1C3 		Google Trust Services LLC
GTS Root R1 		GlobalSign nv-sa
GlobalSign Root CA 		Root CA
GlobalSign Root CA

Firefox (system) ma v zozname certifikovanych autorit (a teda ktorym doverujeme) certifikat GlobalSign Root CA, tento certifikat nasledne overi GTS Root R1 certifikat, ktory dalej overi GTS CA 1C3 certifikat samotnej *.google.com stranky. Mame cely retazec certifikatov, ktore sa navzajom postupne overuju (podpisuju) a na vrchole je tzv. korenovy certifikat, vydany autoritou, ktorej explicitne doverujeme.

Certificates chain for https://www.wikipedia.org
Certificate *.wikipedia.org R3 ISRG Root X1
Subject Name *.wikipedia.org Let's Encrypt
R3 		Internet Security Research Group
ISRG Root X1
Issuer Name Let's Encrypt
R3 		Internet Security Research Group
ISRG Root X1 		Internet Security Research Group
ISRG Root X1

Analogicky ako priklad vyssie, korenova autorita ISRG Root X1, ktorej certifikat sa nachadza v Firefoxe, resp. v systeme (a ktorej verime) overuje v ramci retazca dalsie certifikaty az po samotnu *.wikipedia.org stranku "Verified by: Let's Encrypt". NOTE certifikacna autorita u wikipedia stranok zavisi od viacerych parametrov (napr. umiestnenie serverov) and current vendors are GlobalSign, Digicert and LetsEncrypt.

Platnost certifikatu pre *.wikipedia.org stranku (verified by Let's Encrypt) je 90 dni, platnost Let's Encrypt (verified by Internet Security Research Group) je 5 rokov a platnost Internet Security Research Group (verified by itself) je 20 rokov. To sa samozrejme moze casom menit, zmeni sa majitel certifikacnej autority, certifikat bol napadnuty a pod. Potom sa vyda novy certifikat a povodny certifikat, ktory sa uz stane nedoveryhodny, sa prida do certificate revocation list (CRL). Tento CRL sa pravidelne update-uje, niektore certifikacne autority raz za mesiac, ine napr. raz za rok.

Vydavatel certifikatu (Issuer Name) je autoritou pre vydany certifikat (Subject Name). Na vrchole retazca je root autorita, ktora vzdy vyda certifikat sama sebe (Issuer Name = Subject Name). The root certificate authority (CA) is always signed by the certificate authority (CA) itself. The signatures of all certificates in the chain must be verified until the root CA certificate is reached. More info about Digital certificate (also know as Public key certificate) and Certificate authority.

Zoznam certifikatov, ktore su distribuovane operacnym systemom, a ktore nasledne pouziva (okrem ineho) aj Firefox, mozeme zobrazit napr. prikazom trust(1). Pre este "vacsiu zrozumitelnost" sa pouziva aj termin Trust anchor, co je vacsinou root certificate authority. 

$ trust list  | grep 'ISRG Root X1' -B 1 -A 2
   type: certificate
   label: ISRG Root X1
   trust: anchor
   category: authority

openssl

openssl(1ossl) program pre pouzivanie roznych kryptografickych funkcii a bezpecnych sietovych protokolov.

Certifikat pre konkretnu web stranku mozeme stiahnut priamo z Firefoxu alebo pomocou openssl programu 

$ echo | openssl s_client -connect wikipedia.org:443 2>/dev/null | openssl x509 > wikipedia.pem

Certifikat SSL je v podstate certifikat X.509. X.509 is standard defining the format of public key certificates (digital certificates). X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS. They are also used in offline applications, like electronic signatures. See also [1].

A certificate contains an identity (a hostname, or an organization, or an individual) and a public key (RSA, ECDSA, ED25519, etc.) and is either signed by a certificate authority or is self-signed. 

$ openssl x509 -in wikipedia.pem -noout -text     # see also openssl-x509(1ossl)

# customise the print format
$ openssl x509 -in wikipedia.pem -noout -text -certopt no_pubkey,no_sigdump,no_extensions -nameopt multiline
$ openssl x509 -in wikipedia.pem -noout -subject -issuer -dates -nameopt multiline

There are several commonly used filename extensions for X.509 certificates. Unfortunately, some of these extensions are also used for other data such as private keys.

Filename extensions for X.509 certificates
*.pem Base64 (binary-to-text encoding) certificate (start with -----BEGIN CERTIFICATE-----) PEM
*.crt, *.cer usually in binary form, but Base64 encoded certificates are common too (see *.pem above) PEM
*.p12 may contain certificate(s) (public) and private keys (password protected) PKCS#12
*.crl certificate revocation list (certificates that have been deemed invalid) CRL

PKCS#12 defines an archive file format for storing many cryptography objects as a single file. It is commonly used to bundle a private key with its X.509 certificate or to bundle all the members of a chain of trust. A simpler, alternative format to PKCS#12 is PEM which just lists the certificates and possibly private keys as Base 64 strings in a text file.

CERN Certification Authority

Trust CERN Root Certification Authority

On machines (and Firefox), the CERN Root certificate is not trusted by default, so CERN Certificates will not be verified correctly and cannot be used to authenticate. For this reason, when trying to authenticate with user certificate, some users are getting errors saying something like the page requires a client certificate. On these machines, it will be necessary to install the CERN Root Certificates to trust the CERN (Grid) Certification Authority. The CERN Certification Authority certificates are distributed through the CERN Certification Authorities Files and Documents site. CERN Certification Authority Infrastructure consists of a root certification authority and two intermediate authorities.

Trust the CERN Grid Certification Authority means to import these two files CERN Root Certification Authority 2 Certificate and CERN Grid Certification Authority (1) Certificate in Firefox (Settings: Privacy & Security - Certificates - View Certificates: Certificate Manager - Authorities) and trust this CA to identify websites (and email users).

Tymto sme dosiahli, ze Firefox uz bude mat v zozname certifikovanych autorit (a teda ktorym doverujeme) aj certifikat CERN Root CA, ktorym nasledne moze overit certifikaty niektorych CERN stranok, ktore sa autentifikuju pomocou CERN Grid CA uzivatelskeho certifikatu (vid nizsie).

Trust the CERN Certification Authority means to import CERN Root Certification Authority 2 Certificate (identical as previous) and three files CERN Certification Authority (*) Certificate. Certificates issued by the CERN Certification Authority cannot be used for Grid authentication and are meant for internal CERN usage only (e.g. Code Signing certificates). Tieto certifikaty nie su potrebne pre pracu s Grid.

CERN Grid Certification Authority

Pre pracu na Worldwide LHC Computing Grid (WLCG) je potrebne vlastnit user digital certificate from a Certification Authority (CA) recognized by WLCG. Certification Authorities for WLCG je viacero, ale ako CERN users si vyberieme CERN Certification Authority (CERN CA).

Dalej pri pouzivani terminov "Grid User Certificate" budeme predpokladat CERN Grid User Certificate a "CERN Grid" budeme v skutocnosti hovorit o WLCG.

Teda, ak chceme pracovat na CERN Grid (WLCG) musime vlastnit (CERN) Grid User Certificate. Tento certifikat je potrebne vytvarat kazdy rok, kedze platnost (CERN) Grid User Certificate je prave 1 rok. Prehlad aktualnych uzivatelskych certifikatov, resp. vytvorenie noveho Grid uzivatelskeho certifikatu je mozny na CERN Certification Authority strankach: My User Certificates, resp. New Grid User Certificate, samozrejme je potrebny CERN account. Uzitocne informacie su dostupne na CERN Certification Authority Help.

  • Create new certificate
    https://ca.cern.ch/ca/ → New Grid User Certificate: Request a new Grid User certificate (certificate with a password) → Get Grid User certificate → Download certificate (file myCertificate.p12)
  • Import certificate in Firefox
    Firefox - Settings: Privacy & Security - Certificates - View Certificates: Certificate Manager - Your Certificates: Import (file myCertificate.p12)
  • Convert certificate to PEM format key pair
    To use a certificate (CERN Grid User Certificate) with Globus (CERN Grid), you need to convert it to PEM format key pair in 2 separate files: one for the key itself, and one for the certificate. See also [2].
$ mkdir $HOME/.globus/
$ openssl --version
OpenSSL 3.2.4 11 Feb 2025 (Library: OpenSSL 3.2.4 11 Feb 2025)

# extract certificate (which contains the public key)
$ openssl pkcs12 -in myCertificate.p12 -clcerts -nokeys -out $HOME/.globus/usercert.pem
Enter Import Password:   # type existing passwd from Request a new Grid User certificate web site

# extract the encrypted private key
$ openssl pkcs12 -in myCertificate.p12 -nocerts         -out $HOME/.globus/userkey.pem
Enter Import Password:   # type existing passwd from Request a new Grid User certificate web site
Enter PEM pass phrase:   # must type (min 4 chars) new pass phrase, can be the same as "Import Password"
Verifying - Enter PEM pass phrase:

# permissions by default
  usercert.pem   # (0600/-rw-------)
  userkey.pem    # (0600/-rw-------)
# permissions (recommended) and ownership for PEM Keypair files
$ chmod 0400 $HOME/.globus/usercert.pem
$ chmod 0400 $HOME/.globus/userkey.pem     # can be accessible only by the owner (must have mode 400 or 600)
$ chown $USER:$USER $HOME/.globus/usercert.pem
$ chown $USER:$USER $HOME/.globus/userkey.pem

# pkcs12 certificate is still stored in Firefox
$ chmod 0400 myCertificate.p12
$ mv myCertificate.p12 $USER.cern.grid.certificate.$(date -I -r myCertificate.p12).p12 # and secure backup

V pripade straty, zabudnutia hesla alebo inych problemov s tymito subormi, nie je problem kedykolvek vytvorit novy certifikat (*.p12) a povodny certifikat zrusit (Revoke certificate). Povodny certifikat vsak nie je mozne opatovne stiahnut zo stranky. Existuje vsak moznost vytvorit *.p12 subor z vytvorenych usercert.pem a userkey.pem suborov (vid nizsie).

Takymto sposobom sme ziskali CERN Grid User Certificate provided by the CERN Grid Certification Authority provided by the CERN Root Certification Authority. Zo ziskaneho CERN Grid User Certificate myCertificate.p12, ktory obsahuje public key certificate and private keys, sme vyextrahovali a prekonvertovali do PEM formatu dva subory: usercert.pem public key certificate and userkey.pem encrypted private key. Ake "jednoduche a zrozumitelne".

CERN Grid User Certificate
myCertificate.p12 in Firefox on Web sites (test on page) PKCS#12 file format
usercert.pem and userkey.pem in $HOME/.globus/ on Grid (see below how to test) PEM file format

Ako uz bolo spomenute vyssie, PKCS#12 je komplexnejsi format archivneho suboru, ktory moze zabalit viacero kryptografickych objektov do jedneho suboru, na rozdiel od jednoduchsieho PEM formatu. 

$ openssl pkcs12 -in myCertificate.p12 -info     # see also openssl-pkcs12(1ossl)
Enter Import Password:   # type existing passwd from Request a new Grid User certificate web site

subject=DC=ch, DC=cern, OU=Organic Units, OU=Users, CN=musinsky, CN=728993, CN=Jan Musinsky
issuer=DC=ch, DC=cern, CN=CERN Grid Certification Authority
-----BEGIN CERTIFICATE-----
to same content as file usercert.pem = user certificate with the public key
-----END CERTIFICATE-----

Enter PEM pass phrase:   # must type (min 4 chars) pass phrase, not important for this case (only print info)
Verifying - Enter PEM pass phrase:
-----BEGIN ENCRYPTED PRIVATE KEY-----
meaning as file userkey.pem  = user encrypted private key
-----END ENCRYPTED PRIVATE KEY-----

$ openssl x509 -in usercert.pem -noout -text
$ openssl rsa  -in userkey.pem  -text

Opatovne zabalenie suborov v PEM formate do jedneho PKCS#12 formatu (ktory mozno importovat do Firefox). Export (convert) a PKCS#12 file with data from a certificate PEM file and from PEM file containing a key. 

$ openssl pkcs12 -export -in usercert.pem -inkey userkey.pem -out myReCertificate.p12   # -macalg sha1

Subor obsahujuci certifikat (usercert.pem) je pri akejkolvek transformacii vzdy rovnaky, na rozdiel od userkey.pem, ktory v dosledku sifrovania, ma stale odlisny sifrovaci kluc.

We distinguish between: 1) password for certificate and 2) pass phrase for private key + 3) if verifying (two times) pass phrase or password than we enter new pass phrase or password, 4) otherwise (one time) only enter existing pass phrase or password.

NOTE Pri exporte certifikatu (*.p12) z Firefox moze nastat problem s openssl a s pouzivanim zastaraleho algoritmu [3], [4]. V takomto pripade treba pouzivat openssl pkcs12 with -legacy option.

WLCG usage

Ako uz bolo spomenute, pre pracu na Worldwide LHC Computing Grid (WLCG) je potrebne vlastnit user digital certificate from a Certification Authority (CA) recognized by WLCG. V nasom pripade vlastnime CERN Grid User Certificate vydany CERN Certification Authority, ktoreho platnost je ohranicena na jeden rok.

Jednotlive Grid organizacie boli svojho casu zoskupene v The Virtual Organization Membership Service (VOMS). V 2024-06 VOMS prestal pracovat a je nahradeny by Identity and Access Management (INDIGO IAM) service. V CERNe ma kazdy experiment alebo VO (Virtual Organization) vlastnu WLCG IAM instance, napr. ALICE, ATLAS, CMS a pod.

Latchezar Betev (ALICE Grid admin) e-mail from 2024-06-17:
The VOMS-admin service, used in the past many years for the users registration in the ALICE Virtual Organization (VO), aka the Grid, is being phased out and will stop working at the end of June 2024. It is being replaced by the Identity and Access Management (IAM) service. The registration process is substantially different from VOMS-admin. Step-by-step instructions are given in this document.

ALICE

V pripade noveho uzivatela je potrebne najprv uzivatela registrovat in IAM for ALICE a nasledne link-ovat X.509 certificate to IAM account. Tato procedura sa vykonava na zaciatku len jeden krat. Nie je potrebne link-ovat kazdorocne novo vydany CERN Grid User Certificate (jedine ak by sa menil certificate subject DN, napr. pre certifikat vydany nie v CERNe). Step-by-step instructions are given in this document.

Ako ALICE uzivatel WLCG je potrebne (aspon) raz do roka Re-sign the Acceptable Usage Policy (AUP) in IAM for ALICE (in user profile simple click on "Re-sign AUP"). 

# Test CERN Grid User Certificate on LXPLUS Service
* https://alien.web.cern.ch/
* https://jalien.docs.cern.ch/

# Note that the new JAliEn Grid clients automatically create tokens, while AliEn-ROOT-Legacy (ROOT5)
# requires running alien-token-init manually. There is alien-token-init for JAliEn,
# and you can use it to test your credentials or (re)create tokens manually.

[musinsky@lxplus942 ~]$ ls -la $HOME/.globus/*.pem
-r--------. 1 musinsky z2 3455 Jun 27 14:16 /afs/cern.ch/user/m/musinsky/.globus/usercert.pem
-r--------. 1 musinsky z2 2010 Jun 27 14:16 /afs/cern.ch/user/m/musinsky/.globus/userkey.pem

[musinsky@lxplus942 ~]$ alienv enter O2Physics     # or AliPhysics
[O2Physics] ~ > alien-token-info
File >>><<< not found
[O2Physics] ~ > alien-token-init
Enter PEM pass phrase:
DN >>> C=ch/O=AliEn2/CN=Users/CN=musinsky/OU=musinsky
ISSUER >>> C=ch/O=AliEn2/CN=AliEn CA
BEGIN >>> 2025-07-02 18:35:15
EXPIRE >>> 2025-08-02 20:35:15
[O2Physics] ~ > ls -al /tmp/musinsky/*.pem
-r--------. 1 musinsky z2 1400 Jul  2 22:35 /tmp/musinsky/tokencert_24244.pem
-r--------. 1 musinsky z2 1680 Jul  2 22:35 /tmp/musinsky/tokenkey_24244.pem
[O2Physics] ~ > alien-token-destroy
Token was destroyed! Re-connect for token re-creation.
[O2Physics] ~ > ls -al /tmp/musinsky/*.pem
ls: cannot access '/tmp/musinsky/*.pem': No such file or directory
[O2Physics] ~ >

[musinsky@lxplus936 ~]$ alienv enter xjalienfs
[xjalienfs] ~ > alien-token-info
File >>><<< not found
[xjalienfs] ~ > alien_ls
Enter PEM pass phrase:     # automatically create tokens
# list Grid directory contents
[xjalienfs] ~ > alien-token-info
DN >>> C=ch/O=AliEn2/CN=Users/CN=musinsky/OU=musinsky
ISSUER >>> C=ch/O=AliEn2/CN=AliEn CA
BEGIN >>> 2025-06-30 19:33:06
EXPIRE >>> 2025-07-31 21:33:06
[xjalienfs] ~ > alien-token-destroy
Token was destroyed! Re-connect for token re-creation.
[xjalienfs] ~ >


ToDo (check and simple remove) 

[musinsky@xps13 ~]$ ls -la .globus/*.pem
-r-------- 1 musinsky musinsky 3475 Dec  7 16:10 .globus/usercert.pem
-r-------- 1 musinsky musinsky 1998 Dec  7 16:11 .globus/userkey.pem

musinsky@xps13 ALICE]$ alienv enter xjalienfs/latest
Loading xjalienfs/latest
  Loading requirement: BASE/1.0 Python-modules/1.0-local2 AliEn-Runtime/v2-19-le-local1 XRootD/v5.5.3-local1
Currently Loaded Modulefiles:
 1) BASE/1.0   2) Python-modules/1.0-local2   3) AliEn-Runtime/v2-19-le-local1   4) XRootD/v5.5.3-local1   5) xjalienfs/latest  

Key:
auto-loaded  
Use alienv list to list loaded modules. Use exit to exit this environment.
[xjalienfs/latest] ~/ALICE $> alien-token-init 
Enter PEM pass phrase:
DN >>> C=ch/O=AliEn2/CN=Users/CN=musinsky/OU=musinsky
ISSUER >>> C=ch/O=AliEn2/CN=AliEn CA
BEGIN >>> 2023-05-23 13:49:41
EXPIRE >>> 2023-06-23 15:49:41
[xjalienfs/latest] ~/ALICE $> export | grep -i cert
declare -x X509_CERT_DIR="/home/musinsky/ALICE/sw/fedora38_x86-64/AliEn-Runtime/v2-19-le-local1/globus/share/certificates"
[xjalienfs/latest] ~/ALICE $> exit
exit
[musinsky@xps13 ALICE]$ ls -al /tmp/*.pem
-r-------- 1 musinsky musinsky 1400 May 23 17:49 /tmp/tokencert_1000.pem
-r-------- 1 musinsky musinsky 1680 May 23 17:49 /tmp/tokenkey_1000.pem
Retrieved from "https://muke.saske.sk/mediawiki/index.php?title=Cryptography&oldid=4737"