OpenSSH can use host certificates to verify the host (like SSL certs on a webserver). OpenSSH can also use user certificates to verify the user (like passwords or ssh keys).

Both these types of cert to be used independently of each other.

I've tested using user certificates to authorize user login, since that is what most
people do with keys. People never really verify the host identity.

It works great and it's actually very simple. This will be my new SOP going forward.

Before starting to add hosts and users you need to create a Certificate Authority (CA) - which is actually just a key pair. It's a one-liner.

Every time you create a new host, you just need to copy the same file to it - the public key of the CA. And change one line in sshd_config to allow ssh certificates.

Every time you have a new user on your team who need access to servers, you have to generate a certificate for him. It's a one liner. He will copy the certificate to his own machine. And the ssh client will automatically send the certificate when needed.

Generating certificates is the part that could be automated. You could for instance be given a certificate that expires in 5 minutes. That would allow you to login and stay logged in. But if you need to login again, you need to generate a new certificate.

@Dashrender said in O365 Outbound email issue:

@JaredBusch said in O365 Outbound email issue:

For the record, even though I made the above connector and it failed to verify, I did save the connector. Apparently, that was enough as email is sending now.

So which connector is solving this - the TLS regardless of cert condition, or the No-TLS

I only left the TLS regardless of cert, so it has to be that one.

@JaredBusch said in Create Internal CA for Windows LDAPs and Linux apps:

@pmoncho said in Create Internal CA for Windows LDAPs and Linux apps:

When I export the key, I want to export the private key as well?

That depends. If you are only ever going to have devices using the key to auth against the DC that you created it on, then no.

But if you need to install the cert on a device and then have another device auth to that first device, then that first device needs the private key.

Thank you for the explanation.

@black3dynamite said in Where can I learn more about SSL certs?:

This is 5-part article about setting up your CA is pretty good.
https://devcentral.f5.com/s/articles/building-an-openssl-certificate-authority-introduction-and-design-considerations-for-elliptical-curves-27720

Blog posts on Altaro.
https://www.altaro.com/hyper-v/public-key-infrastructure/
https://www.altaro.com/hyper-v/wsl-offline-root-certificate-authority-windows-pki/
https://www.altaro.com/hyper-v/windows-ssl-certificate-templates/
https://www.altaro.com/hyper-v/request-ssl-windows-certificate-server/
https://www.altaro.com/hyper-v/view-revoke-manually-approve-certificates/

Thanks! I've started to read the info.

Thanks for your suggestions. Taking the results to my client.

@kelly said in Setting up Linux to use Active Directory Certificate Services:

@momurda said in Setting up Linux to use Active Directory Certificate Services:

Have you gone to
http://yourCA.domain.com/certsrv/mscep_admin
If so is it showing a page like in the walkthrough?
Have you tried without enrollment challenge password requirement?

Yes to the first. I used the information there to run the mkrequest.

I haven't tried without a password.

Same error when no password is used in the mkrequest command.

@tim_g said in Replacing a failed CA:

@kelly said in Replacing a failed CA:

@dashrender said in Replacing a failed CA:

@kelly said in Replacing a failed CA:

@tim_g said in Replacing a failed CA:

@kelly In what way is your DC using certificates?

Domain Controller Authorization and Domain Controller.

I ended up just deleting the certs within CertMgr on the DCs themselves, and then requesting new ones. It appears to have fixed the problem.

I was wondering if it would simply be that simple.

I was leery of doing it at first since I didn't know what all was tied to those certs. In the end I just decided to go for it.

You could always export the cert first before deleting it. That way you can always put it back.

Too late for that... cough
0_1510771545875_quote-damn-the-torpedoes-full-speed-ahead-david-g-farragut-342437.jpg

@jimmy9008 said in Domain Trust failed on a VM:

Disconnect the VM from the virtual NIC. Reboot VM from host management. Connect to VM from host management (the VM is now not on the network). Login with domain admin creds. This will be allowed as 'offline login/admin'.

Then put the VM back on to the network whilst logged on and rejoin the VM back to the domain. Then restart. Easy.

Rejoining to the domain will create a new SID. Not sure if that would cause issues for the CA in AD.