I'm trying to logon to domain joined computer using certificate only,
I wonder if it's possible, i read allot on smart card and virtual smart card and both requires ping code.
From what i understand kerberos allows authentication using PKI certificate, so the basic question Is it possible to login the user to the domain using certificate only?
Thanks
Yes. You need to deploy a CA that can issue certificates for users, and configure Active Directory to support certificate authentication. This involves registering a KDC certificate on each Domain Controller and issuing certificates to users. Certificates for interactive logon can be stored in smart cards or TPMs for classic authentication scenarios as well as using e.g. Windows Hello for more modern scenarios.
The basic process is along these lines:
Spin up a Certificate Authority and generate the kerberos/user auth/smart card certificate templates (Example steps
Request certificates for each DC for KDC auth
Request certificates for a given user (enroll cert on smart card)
From there you can require certificates for interactive logons on a per-user basis. There's a bunch of guides on how to do this such as the one linked above.
Related
I have been managing Let's Encrypt's SSL certificates for a domain.
Now I am moving to Amazon API gateway. I will be using the AWS Certificate Manager to generate HTTPS certificates for the root domain and a bunch of subdomains.
If I make the transfer, what happens to my current HTTPS certificate which is associated with my domain. If browsers suddenly start seeing a new HTTPS certificate for a domain, for which they had been getting a different HTTPS certificate until now, would this be a problem?
Also, once I make the shift, what do I do with my current (manually managed) Let's Encrypt certificate? Is there a way to permanently void it?
Szabolcs Dombi says
You can have multiple valid certificates for the same domain at the
same time. Moving from one certificate issuer to another should not
cause a problem.
Toby Osbourn says
SSL certificates don’t last forever, most of them need to be renewed
on a yearly cycle and occasionally you will want to change the type of
the SSL certificate mid-cycle.
Since you are replacing certificates, I suggest you to back up the ones you have.
Once you have backed up the old certificates, just overwrite the .crt and .key files with your new ones. Then, reload your web server so it knows to look at these new certificates, and you should be good to go.
If it's within your interest to know more about how to Generate SSL certificate using Amazon Certificate Manager (ACM), I suggest Barguzar, A. (July 2018). Building Serverless Python Web Services with Zappa. where one can read a good step by step guide. See an excerpt of it below:
ACM is a service that manages and creates SSL/TSL certificates for
AWS-based services and applications. An ACM certificate works with
multiple domain names and subdomains. You can also use ACM to create a
wildcard SSL.
ACM is strictly linked with AWS Certificate Manager Private
Certificate Authority (ACM PCA). ACM PCA is responsible for validating
the domain authority and issuing the certificate.
You can have multiple valid certificates for the same domain at the same time. Moving from one certificate issuer to another should not cause a problem.
This also means that if you create a new certificate the old one still can be used unless it already expired.
I am new to digital certificates and it's various types and applications. What I know/assume as of now is in https communication, a CA will issue a certificate which will basically contain a public-private key pair which the Server and Client will use to communicate securely. And authentication will be through conventional password like mechanisms. Please correct me.
Now in the context of device certificates, does it serve the purpose of authentication only, if yes, then how? or it also serves the purpose of secure communication by means of public-private keys. How it is used.
How does a server determine the authenticity of device?
And in https there is only one certificate that a Server/Host and it's Clients will have, whereas, in device based it's issued per device. Am I right?
Thanks
I'm writing a utility Mac OS X app that basically acts as a web server accepting incoming HTTP requests (think of it as a mock REST API server). I want to be able to support HTTPS, but ideally I'd like to remove the requirement for my users to have to purchase their own SSL certificates.
I've been thinking a little on how I might achieve this. Let's say I register a domain called myapp.com. I then purchase an SSL cert for myserver.myapp.com that is signed by a registered CA. I ship my app with those SSL cert details embedded within it. All my users have to do is update their /etc/hosts file to point myserver.myapp.com to whatever IP address my app is installed and running on.
In fact, by far, the most common scenario would be my app running on the same machine as the client, so I'm considering updating the main DNS entry for myserver.myapp.com to point to 127.0.0.1, and most users wouldn't have to change anything.
So, that's the basic theory. What have I missed that would make this an unworkable plan? A couple of things that have crossed my mind:
I could use a self-signed cert. However, many SSL clients barf (or throw up warnings) if the cert doesn't have a valid CA chain. I'm happy to pay the money for a real cert to alleviate this inconvenience for my users.
I would be embedding the private key for my SSL cert into my app. In theory, someone could extract that and use it to impersonate my app. I guess my reaction is "so what?" My app is a small productivity app, it isn't an e-commerce site. It doesn't collect sensitive info. It literally just simulates web server responses so devs can test their apps.
Any advice/feedback would be greatly appreciated. Thanks.
This won't work - but for nontechnical reasons.
Distributing an SSL certificate to your users along with its associated key will violate the issuance terms of your SSL certificate provider, and they will revoke the certificate when they discover what you have done. (This happened, for example, when Pivotal tried to offer SSL service for developers through sslip.io.) This will, of course, cause your application to stop working.
If your users have administrative access to their machines, they can create and trust their own self-signed CA using Keychain Access. Once they have done so, they could create a certificate (again, using Keychain Access) and insert that into your application to enable SSL.
As said in the other answer you can't ship the same certificate for everybody. What you could do is generate different for everybody:
The application ask them the domain name they want to use (a domain they must own, like myapp.example.com)
The application use the ACME protocol to get automatically a trusted certificate from let's encrypt
Note: you can provide them subdomains of a domain you control (like [clientid].yourappname.yourdomain.com) ONLY of you can register yourappname.yourdomain.com in the public suffix list (because let's encrypt have rate limits)
Background info
Developed a web app that uses IIS8. Currently using IIS to perform client authentication. Server self-signs a certificate and the certificate is imported on specific PCs.
User access site from browser and browser prompts for SSL cert. (Cert is imported to Personal Folder).
For PCs with single accounts there is no issue as i just import the certificate to that account.
For PCs with multiple accounts, if i import the certificate to the Local Computer account the different accounts are unable to access the certificate.
Query
How do i allow multiple accounts to access a single certificate? Tried to grant individual permissions to the individual accounts from the Local Computer Certificates console but to no avail. I do not want to issue the certificate individually to each account.
Is there a solution or alternative to this query?
You should try and separate authentication (using client certs) from account management, meaning authorization.
A good approach might be to use client certificates only to identify the user accessing your application (with exactly 1 certificate for each user). Then setup an n:m mapping to determine that user's groups, which in turn are given specific rights within your application. This is a common way to decouple users and their rights, to facilitate managing each.
According to MSDN documentation, to send more than 500 push notifications per day, your service needs a certificate to establish an SSL tunnel to the WNS.
I see here http://msdn.microsoft.com/library/windows/apps/ff941099(v=vs.105).aspx how to upload the certificate, but how do I get the certificate? Do I need to install the certificate the my web server hosting my services? What if I am hosting my services in Windows Azure?
Firstly, this question is about MPNS (Microsoft Push Notification Service), not WNS (Windows Notification Service). They are two separate services, with WNS being now Microsoft's preferred platform.
Microsoft provides a list of MPNS-approved CA's (certificate authorities) here:
SSL root certificates for Windows Phone OS 7.1
The process for acquiring the certificate is roughly the same with all CA's. You need to create a CSR (certificate signing request) with your domain name as the certificate CN (common name), and send it to the CA. The CA charges a sum for certain validity period (typically 1, 2, or 3 years). Before the SSL certificate is issued, they normally do certain checks to ensure that you really own the domain name, e.g. by mailing the WHOIS owner of the domain and/or asking you to create a special DNS record.
Once you have your certificate, you need to install it as a client certificate in the server that makes the push notification calls to the MPNS servers. How do you do that, depends on your server architecture (.NET, Java, etc.).
http://www.verisign.co.uk/
you need a registered domain name and then you can register to buy a certificate, I think the cheapest I found for my app a few years ago was something like $99 but this may well be incorrect now.
Good Luck,