Certificates for authentication and signing

Cross posting from SO to here for better reach https://stackoverflow.com/questions/62137112/certificates-for-authentication-and-signing

I have a client server scenario.

I have both thick client and a thin client (browser) which communicates with my server.

My thick client uses X-509 system certificate for client certificate authentication scenario and communicates with the server

Also this certificate is used for used to generate signed URL (with expiration time) for my thin client to communicate with my server which is used for integrity and authorization purpose. I also have a token based approach for authentication purpose in this case.

Now i want to complete move my authentication mechanism to OAuth based flow using client credentials or auth code based.

I understand that authentication and authorization can be moved to OAuth based communication. But how do i move my signing (digital signature) based use case to OAuth from certificate based ?

I don’t think there is any other way than to use certificate based PKI mechanism for digital signing. Can the private and public keys be distributed other than the certificates ?

Best Regards,

Saurav

X509 certificates – Are there any naming conventions?

As per the title, what are the naming conventions when buying certificates ?

When buying a cert for TLS / https from a particular Server, naturally I will default to the Server name, for example, if the server is called MOONSERVER under Subject of the x509 Certificate I would set it as MOONSERVER.

Additionally, I need to use another cert for message signing. What shall I call this? What are the rules for valid names? e.g. are hyphens, underscores, etc Ok ? Are names case sensitive?

Algorithm and key size to choose for SSL certificates (security and CPU wise) in 2020 (using nginx)

I posted this question already on SO, but as it is not really a programmin question I thought it might be a better place to ask here:

I want to setup a new SSL certificate store for generating SSL certs (server certs (nginx) and client certs (linux/windows devices))

I’m searching already for quite some time and I’m not sure I fully understand. especially as some articles are a few years old.

Many articles just talk about RSA end seem to recommend 2048 or 3072 though mentioning that 2048 is today probably still the best choice ( https://expeditedsecurity.com/blog/measuring-ssl-rsa-keys/ )

I found for example one Article ( https://paragonie.com/blog/2019/03/definitive-2019-guide-cryptographic-key-sizes-and-algorithm-recommendations ) but it seems to talk mostly about key encryption as @dave_thompson_085 pointed out on SO

stating in the section “Asymmetric (“Public Key”) Encryption”

Use, in order of preference:     X25519 (for which the key size never changes) then symmetric encryption.     ECDH with secp256r1 (for which the key size never changes) then symmetric encryption.     RSA with 2048-bit keys.  The security of a 256-bit elliptic curve cryptography key is about even with 3072-bit RSA.  Although many organizations are recommending migrating from 2048-bit RSA to 3072-bit RSA (or even 4096-bit RSA)  in the coming years, don't follow that recommendation. Instead migrate from RSA to elliptic curve cryptography, and then breathe easy while you keep an eye out for post-quantum cryptography recommendations. 

However they don’t mention the impact on server CPU usage compared to RSA 2048/3072/4048. I also didn’t find many other articles suggesting to switch to Elliptic curve algorithms.

Another article ) https://www.thesslstore.com/blog/you-should-be-using-ecc-for-your-ssl-tls-certificates/ _ tries to promote ECC instead of RSA, but comments on the article state, that ECC is less safe than RSA if quantum computers kick in. And the article cites nowhere numbers for what performance improvement to expect when using ECC.

https://crypto.stackexchange.com/questions/1190/why-is-elliptic-curve-cryptography-not-widely-used-compared-to-rsa mentions potentially legal issues and fear of being sued.

Though CPU usage is not a major issue Id still like to get some idea as I’d like to use the same CA and cert store also on devices like raspberries.

So what is today the best choice for certificate key algorithms and key sizes for server certs (old internet explorer not required but PCs, tablets, mobile phones being used today should be able to connect to the server

and what’s the best choice for client certs (will not be used on mobile devices)?

I kind of tend to RSA 2048, but I’m really not that sure I interpret all the articles correctly and don’t like to make choices based on feelings.

Credential encryption scenarios using certificates

Situation:

  • We have several service accounts (AD) that need to use a limited set of credentials.
  • These service accounts run scripts (PowerShell & Python), etc on different servers, requiring these credentials. These servers all run different versions of Windows Server (2012 – 2016)

Currently the credentials are stored clear text, which is gaping security hole that needs to be fixed.

As we are a Microsoft shop, I initially wanted to opt for DPAPI, but this becomes unwieldy when multiple servers and accounts are used (as you have to store each credential in each combination of vault/server).

The second option was to store the credentials encrypted, on a SMB file share, with NTFS security to limit the accessibility to only the service accounts. The credentials would be encrypted with a certificate, which would be stored in the LocalMachine certificate store of each server. To access a specific credential, the service account would decrypt the file using the certificate.

This seemed like an OK approach:

  • Servers only need to be provisioned with the same certificate (public key is sufficient).
  • Only administrators can access the LocalMachine Certificate Store
  • The credentials are encrypted and stored in a share secured by NTFS permissions.

I then came across a similar implementation as a PowerShell module: PowerShell Credential Vault. The major difference, as far as I can see, is that it stores a randomly generated key, encrypts the credentials (password only) using this key, and then encrypts the key using the certificate. The credentials and the encrypted key are stored together in an XML file.

Is there any advantage over just using the certificate to encrypt the credentials?

Certificates and keys validity

I’m connecting to a server via TLS. My device has installed server cert, device cert, private key and public key.

I read here validity SSL/TLS that TLS cert will last max 2 years.

This means that every 2 years I will have to updat all the certs stored into my device? Only server cert and device cert? Do I have to update also public and private key?

Windows 10 SSTP with self-signed certificates

I can’t seem to get the Windows 10 sstp client to connect to the (router) sstp server

I have tried numerous combinations when creating my self signed certificates (ca & server) but I have to admit that I’m a little stumped

CA : https://prnt.sc/rqtkhv + https://prnt.sc/rqtks0 Server : https://prnt.sc/rqtls4 + https://prnt.sc/rqtm0y

Windows 10 : https://prnt.sc/rqtxsq + https://prnt.sc/rqtyfm

Q1) When installing the certificate in Windows I usually select [Local Computer] certificate store rather than [current user]. Is it normal for Windows to also install a copy in the [current user] store ? If so what is the point of this duplicate certificate installation ?

Q2) When installing the certificate into the “Trusted Root Certificate Authorities” for [current user] I obtain the following warning : https://prnt.sc/rqtoyb – why don’t I get this same warning when installing via [Local Computer] ?

Q3) What is the meaning of the yellow triangle with exclamation mark on both [Basic Constraints] and [Key Usage] ? https://prnt.sc/rqtzj0 + https://prnt.sc/rqtzut

Q4) Why doesn’t the SSTP client (https://prnt.sc/rqu1r5) detect the presence of the previously installed (sstp server’s ca) certificate ? https://prnt.sc/rqu0o0

Q5) I feel like my multiple certificate installation attempts may have ‘polluted’ my Windows’ certificate store. Is this possible ? If so is there a way to ‘clean up’ the certificate store (besides manually deleting unwanted certificates) ?

Q6) I believe that this used to work with Windows 10 before but, maybe because of the regular updates, things seem to have changed ?

regards yann

The Certificate’s CN name does not match the passed value

Each time I teach a network course and we attempt to create and use self signed certificates with the Windows 10 SSTP client we encounter the dreaded “The Certificate’s CN name does not match the passed value” error message

The ca and server certificates are created, signed and trusted We then select the server certificate in the SSTP server settings and export the ca certificate for the Windows PC: https://gyazo.com/10e785b7c51a17572bf40ee85ff744e1

Initially we would specify the sstp (server) router’s IP address as the server CN, and set “ca” as the ca’s CN but recently I have noticed that Windows only accepts the ca if its CN also corresponds to this same IP

We import the certificate on the Windows PC: https://prnt.sc/r7bkhe

Configure the Windows SSTP client : https://gyazo.com/72a61e75c37ed38fdc633b5914729865

And then connect : https://gyazo.com/b034fa2de61f0c33cc665549521d6f52

I assume that the problem lies with Windows but I can’t seem to find where the issue is

Any suggestions ? regards yann

Are SSH certificates more secure for service accounts?

I’m considering how to deploy a service that needs SSH access to many important boxes in my infrastructure. Rather than store a long-lived SSH private key in a key store that the service could request, I’m considering using short-lived SSH certificates to allow SSH access for the service. So the two architectures I’m comparing are as follows (and I’m not mentioning the technologies at play, because I’m more interested in the theory and reasoning):

Public-key auth:

  1. distribute a service account public key to all necessary servers
  2. store private key in secure secrets store.
  3. run service in a role that has access to the private key store

Certificate-based auth:

  1. Distribute a CA cert to all servers
  2. Store CA Key in secure secrets store.
  3. CA service runs in a role that has access to the CA key.
  4. Service generates private key pair and sends CSR to CA service
  5. CA signs and returns certificate with short life span (~5 minutes or long enough to for the service to authenticate to the servers it needs).

Thoughts

The tradeoffs I see, is that with certificate-based auth, compromised certificates are quickly expired and thus less risky. If a service using SSH is compromised, I can revoke it’s ability to request new certificates without having to do any config on any of the servers and without taking away the ability for other such services to authenticate. However, this architecture is more complex, and in the end, the SSHing service still has to auth somehow to the CA server to authorize the signing. Whether this is from a provider role permission, shared secret (hard-coded or accessible by a secrets store), IP address, or some sort of PKI (having the service provided a signed cert by its provisioner).

But whatever the mechanism, is this providing a benefit above and beyond just giving the services access to the private key, because if the services are ever compromised, an attacker can just as easily request a valid cert and use it just as well as a private key.

Is there a method for providing a way of securely authing to the CA server for signing requests that doesn’t require human intervention and is resistant to the service being compromised? Or is there some other benefit to this architecture that would justify the extra complexity?

I don’t want to confuse the discussion too much by bringing specific technologies into it, but to prevent this from being too abstract, this would operate in a kubernetes, EC2, or similar cloud platform where I can provide a set of API permissions to a service from the platform itself using RBAC. The SSH services might be short-lived push-style tasks or long-lived services like Ansible Tower.

Generate digital certificates for employees using the organization’s certificate

I live in Peru and we have a small problem in the organization where I work. Dozens of documents are physically signed daily but this is a waste of time since there are documents that must be signed by more than one person and these people are in different geographical locations.

I am thinking of using digital certificates to sign PDFs but this causes me another problem. Certificates are issued in the name of the Organization, not of the employee who signs. Buying (and processing) the generation of a certificate with legal validity for each employee will take time and money so my question is the following:

Is it possible to generate new certificates for each employee (with legal validity) using our institutional certificate as root certificate?