Hi I studied Push notification, and i find out I have to Creating the SSL Certificate and Keys and I do not know if it cost extra money because on website here it is not written if this service is for free(included in license) or is for extra money.I have bought business license for 99$.
Thanks for help
you have to buy an SSL certificate from a 3rd party website like http://www.verisign.com/
Apple require that you have an SSL certificate to ensure that data sent through their service is being sent in a secure manner
You must create certificates and key with the Apple developper portal :
Turorial here.
Related
Our UWP application will be released outside of the Microsoft Store since it is a Line-Of-Business application. I scoured the internet for references and what I have gathered is that for users to be able to install our UWP application, it needs to be signed with a Trusted Certificate.
A trusted certificate can be obtained from any Certificate Authority(CA) by submitting a Certificate-Signing-Request(CSR) for code signing cert.
Now I haven't tried to get a certificate yet, as it involves payments. So, I want to be sure if I can get a .pfx certificate from the Certificate Authorities for signing our UWP application?
Will CA have the provision to select a Code signing certificate for UWP? and NOT an SSL certificate?
Yes, you should sign your app with a code-signing certificate that is trusted on each device to which you deploy the app.
You would typically use a certificate that is provided by your organization if you belong to one. The other recommended option is to purchase a certificate from a third-party provider whose public root certificate is already trusted by Windows.
If you do a Bing or Google search for "code signing certificate", you should find some trusted providers.
I have a digital certificate but it´s is an card, so I don´t have access to my private key. I am developing an app that I want the user to have an option to log in using its certificate.
I want my application to request user´s certificate.
How do I have to procced?
Request.ClientCertificate.Subject;
Does the job! ;O)
I am trying to create my own certificate for a adobe air application, I created one already based on this link: http://help.adobe.com/en_US/AIR/1.5/devappshtml/WS5b3ccc516d4fbf351e63e3d118666ade46-7f74.html
But when I install my application the publisher field is still set with unknown, which is at the end what I am trying to do, I need to set the publisher with one specific value.
Thanks a lot!
You need to buy a code-signing certificate from a company like Verisign orThawte or another Certificate Authority.
Read this blog by Christian Cantrell for more info on how to get the certificates.
The pages where you can buy the certificate from Thawte and Verisign.
I don't think Thawte allows individuals to buy the certificate, but Verisign does.
Remember, you need to buy the Adobe AIR code signing certificate
A number of Countries have implemented electronic id cards, that their citizens can use to securely access online facilities like banking.
I am interested in learning how to support these cards, but tracking down documentation on how to do this from an IIS hosted website is a real PITA: In MSDN for example the bulk of the smartcard documentation covers the end to end scenario of linking smart cards to domain logins in a corporate environment.
I am just trying to authenticate the holder of - for example, a Spanish DNI-e card and perform an OSCP validation of the card via http://ocsp.dnie.es/
Now, its seems that, rather than explicitly detecting the smart card insertion, I need to create a login page on the server with SSL client authentication forced - but how do I configure one request to require ssl client authentication and to pick the correct client certificate?
Indeed, configure your server to require client certificate authentication. You will receive the client authenticator details in the headers.
You can force to only accept specific certificates by configuring the public root certificate of those client certificates on the server and removing all others that you are not interested in. In the authentication request going from your server to the browser, only the root certificates are listed that are trusted on your server system. The client browser will only offer client certificates that are somehow related to that root.
In an Microsoft environment you would configure your IIS to require SSL on your login page. Additionally, require SSL client authentication using a certificate.
I’m developing an Intranet application and I want to make a secure authentication.
One approach can be use “https”. The problem is that the server doesn’t have a trusted certificate, therefore is a bit annoying for the client because the browser doesn’t trust in the certificate and complaints with a scary message.
Using http will compromise the user password but it can be combined with “Digest access authentication”
What do you think?
As of November 2015 you can't buy certificates for internal domains so as far as I know the only option is to pre-install the certificates on clients. Not a great solution.
Another possability if you want to keep your internal domains private is to create a public domain: mycompany.com, and then run your own DNS server internally that resolves your internal domains: accounting.internal.mycompany.com, hr.internal.mycompany.com and so on. Then I believe you can use a wildcard certificate for mycompany.com. I haven't tested this solution.
These are (y)our options:
If you have mostly Windows hosts, you can Distribute Certificates
to Client Computers by Using Group Policy | Microsoft
Docs
and use your own self-signed certificate in this way.
Non windows users or Windows machines not in the domain will have to
go through the hoops and warnings of either installing the
certificate properly manuallly or allowing the self-signed certificate.
A bad user experience.
You use a proper domain name, a real certificate and a messy DNS
configuration where www.mycompany.com resolves to an external site,
but wiki.mycompany.com is an internal site (But please, please don't put the internal
address for wiki.mycompany.com in an externally visible DNS record!)
You don't use HTTPS at all and use HTTP. Possibly by inventing your
own security for login pages (Yikes!)
They all suck.
Especially if you want to distribute an enterprise-ready onsite app, and you don't know the customer's network and DNS configuration beforehand.
Purchase a domain and trusted certificate? They are really not that expensive anymore if you shop around.
Having said that, digest access authentication is reasonably safe for authentication. Using http rather than https, all of the information you send across the wire will be plain text even if the password is not. Anyone that can plug a laptop in to your intranet running an application such as WireShark can view all of the information sent back and forth. If you care about that information not being compromised, http will not meet your needs.
You have these options:
Purchase a trusted certificate.
Or, generate your own root certificate, install it in browsers on all intranet computers (you should be able to do it since it's intranet), generate your own server certificate signed with your own root certificate. This is actually what companies often do.
Note: Digest access authentication is not helpful if you want to have form authentication (a HTML form with user, password, login page using the visual style of your app, nicer wrong-password error reporting, possibly additional features such as "remember me" or "forgot password").
If you need it to be a fully secure, you should purchase the SSL certificate.
From the wiki link you provided:
Disadvantages
Digest access authentication is intended as a security trade-off; it is intended to replace unencrypted HTTP Basic access authentication which is extremely weak. However it is not intended to replace strong authentication protocols, such as Public key or Kerberos authentication.
I think there's your answer :)